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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sun, 13 Nov 2016 06:40:21 +0000

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.

---

From: Randy Bush <[email-masked]>
Date: Sun, 13 Nov 2016 16:25:36 +0900

> 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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sun, 13 Nov 2016 23:48:06 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote:

randhy

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 Nov 2016 20:23:55 -0500

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

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Nov 2016 17:40:37 -0800

> 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

---

From: Chris Morrow <[email-masked]>
Date: Tue, 29 Nov 2016 21:02:27 -0500

At Tue, 29 Nov 2016 20:23:55 -0500,
"John G. Scudder" <[email-masked]> wrote:
> > 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

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 Nov 2016 21:08:11 -0500

On Nov 29, 2016, at 9:02 PM, Chris Morrow <[email-masked]> 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

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

---

From: Chris Morrow <[email-masked]>
Date: Tue, 29 Nov 2016 22:21:23 -0500

At Tue, 29 Nov 2016 21:08:11 -0500,
"John G. Scudder" <[email-masked]> wrote:
> 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.

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Nov 2016 05:37:24 -0800

>>> and stitching back together the tcp session... same effect.
>> 

< pedantry >

the point is the tcp 'stream' does not have to be hacked in any way.
the hack is at a layer above.

randy

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 30 Nov 2016 09:06:21 -0500

> 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 <[email-masked]> 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

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Nov 2016 06:18:03 -0800

> 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

---

From: Chris Morrow <[email-masked]>
Date: Wed, 30 Nov 2016 10:42:12 -0500

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Nov 2016 08:10:31 -0800

> ideally you also backstop that with some protections (tcp-ao, of
> course!)

and cash will fall from the sky

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 30 Nov 2016 11:20:41 -0500

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 30 Nov 2016 16:57:16 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 30, 2016, at 9:18 AM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:
section 4.5 of 4593 is relevant, or all of sec 4

--John