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
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
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
> 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
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
> 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
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
>>> 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,
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,
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
>
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
> > 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
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:
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,
> 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
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
16 matches
Mail list logo