Subject: [sidr] Comments on draft-pmohapat-sidr-pfx-validate-00.txt

From: Danny McPherson <[email-masked]>
Date: Mon, 17 Nov 2008 14:53:52 -0700

Just to reiterate and expand upon my comments on the
presentation John gave on this draft in SIDR today..

In short, I like the idea as it seems like a viable
stepping stone to employ the work SIDR has been doing
for a while now.

I look forward to newer versions of this work, and
believe it should be adopted under the SIDR WG, with
charter update if need be.

-danny

---

A few specific things:

1) AS path origin-based policies alone are insufficient,
as any targeted attack could most easily spoof the origin
AS.

2) When I brought up the issue about targeted attacks
John said this is meant to accommodate the 80/20 rule
with route leaks, etc.  When routes are leaked, which
appears to be the most common 'hijack' case today, the
origin is preserved.  This wouldn't necessarily protect
against that.

3) No inherent ability in the current validation modes
to prefer shorter validated prefixes over longer non-
validated ones means that most hijacks would still prefer
the hijacked more-specific prefix.  Most actual hijacks,
and even leaks such as the YouTube incident, are from
more specific prefixes and given preference.

4) Requiring implementations to store prefixes in their
respective Adj-RIB-In, even if they've been filtered,
such that they're available if policies changes, is a
bad idea.  Instead, as Jeff suggested at the microphone,
employing route refresh in these scenarios would be
much more scalable.

E.g., in the case of CTBC last week there were like
267k prefixes leaked that would have been stored and
filtered, were these capabilities in place.  This could
easily become a DOS vector itself.

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Mon, 17 Nov 2008 17:21:29 -0800

Hi Danny,

Thanks for the comments.

| A few specific things:
| 
| 1) AS path origin-based policies alone are insufficient, as any
|    targeted attack could most easily spoof the origin AS.

Yes, and that's why complete path attestation is still required and
needs to be addressed.

| 2) When I brought up the issue about targeted attacks John said this
|    is meant to accommodate the 80/20 rule with route leaks, etc.  When
|    routes are leaked, which appears to be the most common 'hijack'
|    case today, the origin is preserved.  This wouldn't necessarily
|    protect against that.

I am not quite sure I follow this. But if the origin is preserved and
the AS_PATH is not, it should again be addressed by path attestation.

| 
| 3) No inherent ability in the current validation modes to prefer
|    shorter validated prefixes over longer non- validated ones means
|    that most hijacks would still prefer the hijacked more-specific
|    prefix.  Most actual hijacks, and even leaks such as the YouTube
|    incident, are from more specific prefixes and given preference.

>From the point of view of origin validation, prefixes with different
mask lens are treated as completely different route advertisements and
validated separately. So if a BGP speaker receives both 10.1.1/24 and
10.1/16, they are two separate prefixes, each undergoing the
validation check. If the rightful owner of 10.1/16 prefix block is
AS#1, I would expect AS#1 to have originated an ROA as {10.1/16,
max_length=24}. When the BGP speaker receives 10.1/16 with origin AS
1, that would be declared "valid". However when it receives 10.1.1/24
with origin AS 2, since the ASs do not match for the ROA found, it
would be declared "invalid". So that seems to take care of the issue
you raise.

| 4) Requiring implementations to store prefixes in their respective
|    Adj-RIB-In, even if they've been filtered, such that they're
|    available if policies changes, is a bad idea.  Instead, as Jeff
|    suggested at the microphone, employing route refresh in these
|    scenarios would be much more scalable.
| 
| E.g., in the case of CTBC last week there were like 267k prefixes
| leaked that would have been stored and filtered, were these
| capabilities in place.  This could easily become a DOS vector itself.

It's a trade-off. With route refresh mechanism, you will be forced to
send a route refresh request to each of your peerings when the policy
changes and receive all of the 267K prefixes again. That's not nice
from CPU viewpoint. Agree you can be clever about storing some hints
of which peers had sent you invalid routes and send the request to
them or build a prefix ORF based on what prefixes have database
updates etc..., but that's ugly. If you choose to store them, you are
storing them only from your configured peers. So it's not an unbounded
problem. 
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: [email-masked]
Date: Tue, 18 Nov 2008 15:53:04 -0500

Quoting "Pradosh Mohapatra (pmohapat)" <[email-masked]>:

> max_length=24}. When the BGP speaker receives 10.1.0.0/16 with origin AS

The capability in any algorithm to distinguish between an update
due to path or origin change by legitimate owner's action vs.
that due to a hijack/misconfiguration attack would remain challenging
as long as RPKI adoption and creation of ROAs is partial.
The legitimate owner of 10.1/16 can be multi-homed to, say,
AS#1 and AS#2. They may have created a ROA for
10.1.0.0/16, Origin = AS#1, but may not have yet created a ROA
for 10.1.1.0/24, Origin = AS#2. There is also the lag issue.
They may have created the second ROA in the last few hours
and propagated an update with different origin (AS#2) shortly
after that, but the algorithm downloads ROAs only once every 24 hours.
So the algorithm fails to validate based on the currently known ROAs
at the BGP speaker.

During the evolution period of RPKI,
origin and path validation algorithms can benefit from combining
(prefix, origin AS) pairing information from different sources,
including trace data (e.g., routeviews, RIPE-RIS) and even
RPSL/SWIP route registration data from IRR/RADB.
This would be especially useful when there is incompleteness
in the ROA repository.
Some examples of ideas (research) along these lines:
http://www.cs.unm.edu/~treport/tr/06-06/pgbgp3.pdf
http://www.antd.nist.gov/~ksriram/NIST_BGP_Robustness.pdf

Sriram

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 18 Nov 2008 19:34:59 -0500 (Eastern Standard Time)

> Yes, and that's why complete path attestation is still required and

SIDR was chartered to fulfill the security requirements established by the 
rpsec working group.  That group was able to set path origination as a 
security requirement but failed to come to consensus of what sort of 
additional path security should be required.

No one in the rpsec wg argued that additional path security is NOT 
required, it was just setting the exact security requirements for security 
for the AS_PATH past the origination AS that was contentious.

So everyone recognizes that the origination of a route to a prefix 
is not sufficient.  But it is necessary.  It is the starting point of 
every suggested BGP protection that provides more protection of the 
AS_PATH.  (That I have seen.)

So we'll get done with this (someday!) and we can continue with more work 
to further protect the AS_PATH and this current work will be useful in the 
meantime and the basis for the more work (i.e., not wasted).

--Sandy

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Nov 2008 11:49:47 +1100

On 19/11/2008, at 11:34 AM, Sandra Murphy wrote:

> SIDR was chartered to fulfill the security requirements established  
> by the rpsec working group.  That group was able to set path  
> origination as a security requirement but failed to come to  
> consensus of what sort of additional path security should be required.
>
> required, it was just setting the exact security requirements for  
> security for the AS_PATH past the origination AS that was contentious.
>
> is not sufficient.  But it is necessary.  It is the starting point  
> of every suggested BGP protection that provides more protection of  
> the AS_PATH.  (That I have seen.)
>
> So we'll get done with this (someday!) and we can continue with more  
> work to further protect the AS_PATH and this current work will be  
> useful in the meantime and the basis for the more work (i.e., not  
> wasted).
>

WG Co-Chair Hat ON

To add a couple more words here to Sandy's, when RPSEC can resolve  
their outstanding considerations related to the specification of  
requirements with respect to securing the AS paths of BGP route  
updates, then the charter of SIDR indicates that we can then work on  
ways to meet such requirements. And in saying this I am aware that  
this has been outstanding for some years now, and the RPSEC draft,   
draft-ietf-rpsec-bgpsecrec-10.txt is still awaiting a clear consensus  
from the RPSEC WG. However the alternative, of enjoying a word-for- 
word replay of the entire RPSEC discussion on possible AS path  
validation approaches and their relative merits in SIDR does not  
strike this particular WG co-chair as a productive activity for the  
SIDR WG. So at this point we are still awaiting RPSEC to complete on  
its charter before heading off into AS Path validation approaches.

Geoff