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

[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

[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

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

[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, only it's an inferior version because there's a
> greater audit trail.

yes.

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

baroque.

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

--John
___
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 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 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 community indicating that the route is invalid; the
> > communities are not protected.  This action could result in
> > inconsistent routing or in even a DoS.  I know the document is not
> > explicit about what to do with the validation state (which is ok),
> > but the clear intention (from rfc6811 and rfc7115) is that it will
> > be used to make routing decisions.  Please add some text about this
> > potential issue.
> 
> I started to write something about this and then realized I don't
> understand what you mean. At first I thought you were saying that an
> attacker that can forge an OV community can bias route
> selection. While this is true of course, it's also not unique to OV
> (Localpref has this property for example). It probably wouldn't be
> hard to write a sentence to summarize this, if necessary.
> 
> However, you specifically refer to the invalid state: "a router in the
> path ... can inject a community indicating that the route is
> invalid". This makes me think you think there's something special
> about "invalid", and I don't know what it is. You also say something
> about the sorting order, which I'm also not sure why that would
> matter.

I read this with the implicit: "Of course 'invalid == drop'."

So, if between an edge/core nodes you marked the edge -> core prefix
stream (mid-stream) with 'invalid' the core may discard all routes
seen and so marked.

This COULD move traffic away from a single edge node (or nodes) and
bias traffic across longer/other paths OR it could isolate folk behind
the edge node(s).

Of course, just wiping out the prefixes in flight and stitching back
together the tcp session... same effect.

-chris

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

> > 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 community 
> > indicating that the route is invalid; the communities are not protected.  
> > This action could result in inconsistent routing or in even a DoS.  I know 
> > the document is not explicit about what to do with the validation state 
> > (which is ok), but the clear intention (from rfc6811 and rfc7115) is that 
> > it will be used to make routing decisions.  Please add some text about this 
> > potential issue.
> 
> I started to write something about this and then realized I don't understand 
> what you mean. At first I thought you were saying that an attacker that can 
> forge an OV community can bias route selection. While this is true of course, 
> it's also not unique to OV (Localpref has this property for example). It 
> probably wouldn't be hard to write a sentence to summarize this, if 
> necessary. 
> 
> However, you specifically refer to the invalid state: "a router in the path 
> ... can inject a community indicating that the route is invalid". This makes 
> me think you think there's something special about "invalid", and I don't 
> know what it is. You also say something about the sorting order, which I'm 
> also not sure why that would matter.
> 
> As far as I can tell, injecting "a community indicating that the route is 
> invalid" is kind of boring attack -- it just makes the route less likely to 
> be selected by the downstream router. The "bad" router could also just fail 
> to propagate the route at all ("underclaiming") making it flat-out impossible 
> for the downstream to select it, or could use any number of other path 
> attribute manipulations (Localpref, AS path, etc) to make the route less 
> preferable. Are you suggesting there is some fancier attack than this, or are 
> you just asking us to acknowledge BGP doesn't work very well in the face of 
> an on-path attacker?
> 
> By all means, if anyone has text to send, do.

you have out-sourced your security.  the party to which you have out-
sourced it can send you anything.  get over it.

as the OV signaling is vanilla bgp, there is no integrity enforcement,
not even a useless checksum; any monkey in the middle can fake anything.
get over it.

none of this is new.  you'll really love the wonderful new blackhole
community.

randy

___
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 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:  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 community indicating that the 
> route is invalid; the communities are not protected.  This action could 
> result in inconsistent routing or in even a DoS.  I know the document is not 
> explicit about what to do with the validation state (which is ok), but the 
> clear intention (from rfc6811 and rfc7115) is that it will be used to make 
> routing decisions.  Please add some text about this potential issue.

I started to write something about this and then realized I don't understand 
what you mean. At first I thought you were saying that an attacker that can 
forge an OV community can bias route selection. While this is true of course, 
it's also not unique to OV (Localpref has this property for example). It 
probably wouldn't be hard to write a sentence to summarize this, if necessary. 

However, you specifically refer to the invalid state: "a router in the path ... 
can inject a community indicating that the route is invalid". This makes me 
think you think there's something special about "invalid", and I don't know 
what it is. You also say something about the sorting order, which I'm also not 
sure why that would matter.

As far as I can tell, injecting "a community indicating that the route is 
invalid" is kind of boring attack -- it just makes the route less likely to be 
selected by the downstream router. The "bad" router could also just fail to 
propagate the route at all ("underclaiming") making it flat-out impossible for 
the downstream to select it, or could use any number of other path attribute 
manipulations (Localpref, AS path, etc) to make the route less preferable. Are 
you suggesting there is some fancier attack than this, or are you just asking 
us to acknowledge BGP doesn't work very well in the face of an on-path attacker?

By all means, if anyone has text to send, do.

Thanks,

--John
___
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)]

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, "Randy Bush" > wrote:

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 (yes, even an internal router) can inject a
community indicating that the route is invalid; the communities are
not protected.  This action could result in inconsistent routing or in
even a DoS.  I know the document is not explicit about what to do with
the validation state (which is ok), but the clear intention (from
rfc6811 and rfc7115) is that it will be used to make routing
decisions.  Please add some text about this potential issue.

would you prefer a revision soon, or wait for other iesg comments?

randhy

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

> 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 (yes, even an internal router) can inject a
> community indicating that the route is invalid; the communities are
> not protected.  This action could result in inconsistent routing or in
> even a DoS.  I know the document is not explicit about what to do with
> the validation state (which is ok), but the clear intention (from
> rfc6811 and rfc7115) is that it will be used to make routing
> decisions.  Please add some text about this potential issue.

would you prefer a revision soon, or wait for other iesg comments?

randhy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[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 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 
(yes, even an internal router) can inject a community indicating that the route 
is invalid; the communities are not protected.  This action could result in 
inconsistent routing or in even a DoS.  I know the document is not explicit 
about what to do with the validation state (which is ok), but the clear 
intention (from rfc6811 and rfc7115) is that it will be used to make routing 
decisions.  Please add some text about this potential issue.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr