Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-12-02 Thread Randy Bush
i realized you wanna ietf last call it. will push a rev in a few hours. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-30 Thread 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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-30 Thread 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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-30 Thread 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

2016-11-30 Thread 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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-30 Thread 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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-30 Thread 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

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-30 Thread 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,

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-29 Thread Chris Morrow
At Tue, 29 Nov 2016 21:08:11 -0500, "John G. Scudder" wrote: > > On Nov 29, 2016, at 9:02 PM, Chris Morrow wrote: > > Of course, just wiping out the prefixes in flight > > Right, exactly. The OV "attack" is just a baroque version of > underclaiming,

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-29 Thread John G. Scudder
On Nov 29, 2016, at 9:02 PM, Chris Morrow wrote: > Of course, just wiping out the prefixes in flight Right, exactly. The OV "attack" is just a baroque version of underclaiming, only it's an inferior version because there's a greater audit trail. > and stitching back >

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-29 Thread Chris Morrow
At Tue, 29 Nov 2016 20:23:55 -0500, "John G. Scudder" wrote: > > On Nov 13, 2016, at 1:40 AM, Alvaro Retana (aretana) > wrote: > > C1. The reference to rfc7607 should be Informative. > > Done (in -10 candidate source). > > > C2. [Major] Security

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-29 Thread Randy Bush
> > C2. [Major] Security Considerations. I think that there is one > > consideration that should be mentioned in this section: Given that the > > largest value is preferred (2 = invalid), there is an attack vector where a > > router in the path (yes, even an internal router) can inject a

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-29 Thread John G. Scudder
On Nov 13, 2016, at 1:40 AM, Alvaro Retana (aretana) wrote: > C1. The reference to rfc7607 should be Informative. Done (in -10 candidate source). > C2. [Major] Security Considerations. I think that there is one consideration > that should be mentioned in this section:

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-13 Thread Alvaro Retana (aretana)
Either way is fine. The document is scheduled for the Telechat on Dec/15. I expect maybe a couple of directorate reviews before that – if they come in by Dec/9 and you have time to pdate, then please do. Otherwise, let’s wait for the IESG to comment. Thanks! Alvaro. On 11/13/16, 4:25 PM,

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-12 Thread Randy Bush
> C1. The reference to rfc7607 should be Informative. > > C2. [Major] Security Considerations. I think that there is one > consideration that should be mentioned in this section: Given that the > largest value is preferred (2 = invalid), there is an attack vector > where a router in the path

[sidr] AD Review of sidr-origin-validation-signaling-09

2016-11-12 Thread Alvaro Retana (aretana)
Dear authors: Hi! I have a couple of comments about this document (below). I am going to start the IETF Last Call, and schedule it in the next IESG Telechat, with the expectation that my comments will be addressed before then. Thanks! Alvaro. C1. The reference to rfc7607 should be