Subject: Re: [sidr] [Idr] Route Leaks and solutions

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 9 Jul 2015 17:14:29 +0000

(Cc'ing sidr list also since there is interest there too in this topic.)

>> If A's customer C does not want A to propagate, then C has a choice not to send
>> the prefix-route to A in the first place.
>> Given that choice, why would C instead choose to poison or downgrade by altering RLP bits?

>Q: why do people poison routes by jamming in to the aspath ASN which
>they want to ignore their prefix/announcement?
>A: because knob.

Section 5.1 in the route leaks solution draft already discusses possible abuse 
of the knob (without security / bgpsec).
Randy and I were trying to come up with more examples (besides what is in Sec. 5.1).
I will include Randy's additional example (that we have discussed here) also in Section 5.1. 
But, IMHO, so far none of these abuses seems egregious.
So the benefit seems to outweigh the 'new attack vector' disadvantage. Explained further below.

Even with ROA origin validation, there is the fake-origin-AS attack vector (without bgpsec),
but we recognize that ROA origin validation stops all accidental mis-originations. So it is worth it.  
The determined attacker may still use fake-origin-AS attack; 
but that would be mitigated by bgpsec (when it is deployed). 
 
Likewise, the evolution path for route leaks solution could be as follows:

Current BGP (without route leak solution; assuming prefix /AS path filters aren’t doing job adequately)

--- Vulnerable to accidental and malicious route leaks

--- Let us say 99% are accidental and 1% malicious (you can substitute your numbers)
  
  |
  |
  \/

BGP with proposed route leak solution (without bgpsec)

--- Detects/mitigates the 99% but not the 1%

  |
  |
  \/
  
Proposed route leak solution with bgpsec
       
--- Detects/mitigates the 99% as well as the 1%

Sriram

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 14 Jul 2015 10:43:07 +0200

Hi,

Sriram, could you please elaborate what the difference is between the
route-leak detection (and action) for customers and peers.

It seems to me that sections 3.2.1. and 3.2.2. propose the same
algorithm (modulo the BGP neighbor is a customer or a peer). The
difference in the "possible actions" (3.3.) is not clear to me either.

Finally, what is the proposed action when an RLP-marked update is
received from an upstream?

Thanks,

Andrei

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 15 Jul 2015 13:03:39 +0000

Andrei,

Thank you for reading the draft and offering comments -- certainly very helpful
towards refining the proposal as well adding greater clarity in the document.

>algorithm (modulo the BGP neighbor is a customer or a peer). 

Your observation is correct. It has to do with the semantics of RLP bits.
For now, we have RLP = 00 (default; nothing said) and RLP = 01 ('do not propagate up').
'Do not propagate up' certainly means that the update should not subsequently 
propagate from a customer to its provider.
However, a receiver can (at its own discretion) interpret RLP = 01 more strictly 
to mean 'do not propagate to provider or peer'. 
That is because if an ISP is not supposed to forward an update with RLP = 01 
'up' to a provider, then normally it should not forward it 'laterally' to a peer either.
So we have separated the receiver detection procedures for 
(a) when the update comes from a *customer* (section 3.2.1), and 
vs. (b) when it comes from a *peer* (section 3.2.2).
The difference is the stricter interpretation (in Section 3.2.2) of RLP = 01.
Initially the attempt is to see if we can keep the RLP semantics simple,
and still accomplish the detection objectives w.r.t. customer/peer. 
These two section can be merged into one if, for example, 
RLP = 01 is specified to denote 'do not propagate to provider or peer'.  

>The difference in the "possible actions" (3.3.) is not clear to me either.

When an update is detected and 'marked' as 'route leak' (based on section 3.2.1 or 3.2.2 detection),
then the same/similar method(s) of mitigation can be applied (in the two cases). 
The draft should not specify a mitigation method because that is left to operator policy.
So we describe only an *example* policy: Suspend the "prefer customer" policy;
i.e. instead of a 'marked' update from a customer, prefer an 'unmarked'
update from a provider or peer. Some similar policy can be applied for a peer. 
Let the operator decide the actual policy to be used in each case.

>received from an upstream?

Good point. The draft currently does not discuss this. If the customer
is single-homed and does not have any alternate path for the prefix,
then it would install the route learned from its sole provider even if it is 'marked'.
If the customer is multi-homed, it should prefer an 'unmarked' update from 
one provider over a 'marked' update from another provider. Etc.
Again these actions/methods are left to operator policy.
However, in the next revision, we will include a subsection to outline this.  

Sriram

---

From: Andrei Robachevsky <[email-masked]>
Date: Wed, 15 Jul 2015 17:00:22 +0200

Thank you for your response, Sriram.

Let me understand the semantics of the RLP field better. I am assuming
that it indicates that a leak happened somewhere in the path, not
necessarily at the adjacent AS (your customer or your peer). If this is
indeed so, the only case I can think of when an RLP-marked update is not
a leak, is when it came from the upstream.

And if we follow the same logic an RLP-marked update from the upstream
can still be a leak (and not just downstream announcements), but I think
it would be difficult to distinguish between the two.

If my considerations are correct, there are only two cases -
upstreams/transit providers, for which RLP doesn't matter, and others
(customers and peers) where an RLP indicates a leak and has to be dealt
accordingly.

Related to the latter - what would be in your opinion a reason to accept
a leaked route? Is it just for reachability (i.e. only one route to the
destination), or are there "legitimate" cases for route leaks?

Thanks,

Andrei

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 15 Jul 2015 21:20:38 +0000

>that it indicates that a leak happened somewhere in the path, 

RLP field does not indicate (or encode) that a *leak happened*.
It merely facilitates a receiving router to detect if an update
from a sending router (an adjacent AS) is a route leak. 

Example 1: Route for prefix P propagates as follows: 

P---AS A  ---{ RLP(AB) = 01 }---> AS B (cust. of A)  ---{ RLP(BC) = 01, RLP(AB) = 01 }--->  AS C (cust. of B) 

Sequentially, B is a customer of A, and C is a customer of B.    
The expression in wiggly brackets {} shows the RLP values in the prefix update.
A transitive RLP field is added in the update for each hop in the path. 
Each AS sets an RLP value for its hop to the next AS for the route it forwards for prefix P.
RLP = 01 indicates that the update SHOULD NOT be sent 'up' to a provider (or 
'laterally' to a peer), but it is allowed to forward the update to a customer.
So no one in this Example 1 detects a route leak. There is no route leak. 

Example 2:

P---AS A  ---{ RLP(AB) =01 } ---> AS B (cust. of A)  --- { RLP(AB) =01, RLP(BC) =00) } --->  AS C (provider of B)

B (in the middle) has two providers A and C.
B learned a route from A and is leaking the route to C, and C detects it.
C looks at RLP(AB) = 01, and therefore it knows that B's update is a leak.
So C marks B's update as a route leak.  

>not necessarily at the adjacent AS (your customer or your peer). 

As in the examples above, the receiver is only detecting if the update from 
its adjacent router is a route leak. It does so by looking 
at NOT the RLP field value set by the adjacent router 
but the RLP field values set by the ASes that preceded it.

>If this is indeed so, the only case I can think of when an RLP-marked update is not

May be this question goes away in light of the proper understanding 
of RLP field values provided above.
It is true that an upstream provider cannot leak any prefix route to its
customer by definition. Any prefix routes that the upstream has accepted 
(after applying route leak detection/mitigation etc.), the upstream usually send all
those routes to its customer (except those learned from that customer). 
So in general, a customer need not try to detect route leak from its upstream provider
(keep in mind that we are talking about the relationships on per prefix basis).
(Please ignore what I said in my previous reply to you about detecting route
leaks from a provider; the last paragraph.)

We have not used the term "RLP-marked" anywhere in the draft.
So I don't know what exactly you mean by it.
But hopefully the above explanations clarify things for you.
When we say an update is 'marked', it simply means that it was detected 
to be a route leak (as it was received from a neighbor AS). 

>(customers and peers) where an RLP indicates a leak and has to be dealt

Yes, I agree that detecting route leaks from customers/peers matters.
Detecting route leaks from upstreams/transit providers does not really matter
(as explained above).

>destination), or are there "legitimate" cases for route leaks?

In this discussion and the draft, we have not called anything a
"legitimate" route leak. But some customer ASes could make mistakes.
For example, if X is single-homed stub customer of Y and Y is a customer of Z,
and if X sets RLP = 01 by mistake in its prefix update to Y, then Z detects and marks
the prefix route from Y as a route leak. 
Z will not have any alternate path for that prefix because X is single-homed stub.
In this case, Z may accept the update for reachability even though it was
detected to be route leak. Again, we don't specify this. 
We only specify the detection method, not the mitigation policy.
 
Thank you.

Sriram

---

From: Andrei Robachevsky <[email-masked]>
Date: Thu, 16 Jul 2015 10:13:57 +0200

Sriram,

Your explanations make it very clear, thanks.

>> not necessarily at the adjacent AS (your customer or your peer). 

Yes. What I meant here is a case when you extend your example to AS D (a
peer or a provider of AS C). Assuming that AS C has no route-leak
mitigation policy and propagates the update further, AS D may detect the
leak, which happened somewhere in the path (where precisely - D does not
know and does not need to know).

The only thing that matters is that the update has the RLP field set to
'01' indication for one or more hops (excluding the most recent) in the
AS path (that is what I called the RLP-marked in my note) *and* it does
not come from the upstream/transit provider.

[...]
> Detecting route leaks from upstreams/transit providers does not really matter

I guess what I am arguing for is that the semantics of RLP 01 should be
"propagate only down" rather than "do not propagate up" and any updates
with the RLP field set from a peer or a customer should be treated as a
leak.

Thanks,

Andrei

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 17 Jul 2015 13:40:37 +0000

>Your explanations make it very clear, thanks.

Thanks, Andrei. 
Looks like we've converged on pretty much all issues that we've discussed so far in this thread.
One comment inline below.

[...]

>with the RLP field set from a peer or a customer should be treated as a

OK, I see now what you meant. Your suggestion is good. 
In the draft, currently in Section 3.2.2 "do not propagate up" 
is interpreted (implicitly) as "propagate only down" for a peer.  
But with this change (as suggested above by you) , we no longer have to 
make that distinction. The semantics of RLP 01 would be the same 
whether an update is received from a customer or a peer. 
Then route leak detection algorithm would be the same for customer or peer,
and sections 3.2.1 and 3.2.2 can be merged into one. Thanks.

Sriram

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 20 Jul 2015 10:22:09 -0400

I think I see the current plan as a it challenging to depend upon...

If the RLP bit is dependent upon ops folks getting the right
config-bit set for each customer we would want that to be as much
automated as possible so there would be the least chance for 'forgot
to set the bit' or 'set bit incorrectly'.

I'm worried that I can't tell reliably what the bit was 2 as-hops
away, did they mean 'customer' ? or was that a mistake? Did someone
change it mid-path to me? Did the implementation of their vendor gear
change/set the wrong attribute value?

There seem to be a bunch of uncertainties with this, in my mind. I
guess that with bgpsec signing this attribute at least 'joe really
meant that jim was his customer', and you can't change the value on a
bgpsec path.

If we want that, I think having the attribute where it can get changed
(not-bgpsec secured paths) is a real problem, or opens up some pretty
large problems...

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 21 Jul 2015 16:56:45 +0000

>to set the bit' or 'set bit incorrectly'.

Some sort of mapping of a prefix-route to eBGP neighbors to who it will be sent to, 
namely, customers, peers, providers, isn’t that done already in a routers currently?

>change/set the wrong attribute value?

Initially, only the big ISPs have to get it right (setting the RLP bits). 
That itself would help reap the benefit substantially.
Basically, then one big ISP’s prefix-routes sent to its customer cannot make  
a U-turn (route leak) somewhere in its customer cone and be accepted by another big ISP,
even if the ASes in between are not doing it (or they make mistakes with their 
RLP bits) as long as they do not change any preceding ASs' RLP fields.    

>(not-bgpsec secured paths) is a real problem, or opens up some pretty

Like I said in my talk in GROW yesterday, without bgpsec (RLP bits secured), 
the 99% accidental leaks are detected/mitigated but not the 1% malicious.  
With bgpsec (RLP bits secured), the 1% malicious are also detected/mitigated.  
See slide 5:
https://www.ietf.org/proceedings/93/slides/slides-93-grow-4.pdf 

Prior to bgpsec protection, there are two types of attacks that
are possible on unprotected RLP bits:

1. Upgrade attack (RLP = 01 is altered to RLP = 00) to avoid route-leak detection. 
That falls in the 1% malicious category (undetected) but no other 
more egregious damage occurs as a result of this upgrade attack.
See more discussion of this in Section 5.1. of the draft:
https://www.ietf.org/id/draft-sriram-idr-route-leak-detection-mitigation-01.txt 

2. Downgrade attack: (RLP = 00 is altered to RLP = 01) 
This does not matter in the 'down' direction because RLP =01 
always allows propagation of the prefix-route in 'down' direction.
So this attack (RLP = 00 --> RLP = 01) matters only when update propagates 
in the up or lateral peer direction.
That would only mean that an alternate update that is not labeled a route leak 
would be preferred by the (provider or peer) over this one.
And if there is no alternate update, then for reachability,
the only prefix-route that seems like a leak might still be accepted.
But this is left up to operator policy.       

Sriram