Subject: Re: [sidr] Fwd: I-D Action: draft-ietf-sidr-pfx-validate-02.txt

From: Pradosh Mohapatra <[email-masked]>
Date: Tue, 2 Aug 2011 23:58:13 -0700

Hi Roque,

Thanks for the review and comments.

> General Comment:
>   " Depending on the lookup result, we define a property for each route,
>    called the "validity state".  It can assume the values "valid", "not
>    found", or "invalid"."
> 
> You may want to consider calling it "Origin AS validity state" to distinguish it from the validity state in BGPSEC ("valid" and "invalid").

Ack.

> Section 1:
> p2: s/verifyable/verifiable

Ack.

> Section 2:
>    "An AS can originate more than one
>    prefix set.  Thus, multiple prefix sets in the database can contain
>    the same origin AS(es)."
> 
> I believe you also need to mention that in the table there may be "multi-origin prefixes". Geoff report identifies 2400 but you may find more in local/regional environments (http://bgp.potaroo.net/as6447/report.txt).

I looked at the document again and I see many places where we say there can be multiple origin ASes for the prefix. E.g.:

we define terms "UPDATE prefix" and "UPDATE origin
AS number" to denote the values derived from the received UPDATE message, and
"database prefix set" and "database origin AS number set" to mean the values
derived from the database lookup.

where it's defined as "database origin AS number set" instead of just an AS number.

> 
> Section 5:
> p5: 
> I believe you should reference draft-ietf-sidr-origin-validation-signaling-00

Ack

> Security Consideration:
> I think you need to consider what you already mentioned in section 4, if the connectivity to the local-caches is lost, invalid routes will be classified as "not-found", which could have a different set of local policies.

Is this different from current behavior?

- Pradosh

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 3 Aug 2011 12:03:24 +0200

Hi Pradosh,

(skiping)

> where it's defined as "database origin AS number set" instead of just an AS number.

Ok. I got it now.

> Is this different from current behavior?

Not sure what do you refer for "current behavior". My point was that in the security considerations you should point to the analysis in Section 4 on loosing connectivity to the cache servers.

Example:
	Router set loc-pref 100 for "valid" and loc-pref 50 for "not-found".
	If the router looses connectivity with caches, either by operational issues or by malicious event (on the cache/ the router or the network between the two), the set of prefixes that should be "valid" based on RPKI will be classified as "not found" and loc-pref set to 50.

Roque

---

From: Pradosh Mohapatra <[email-masked]>
Date: Fri, 19 Aug 2011 23:53:34 -0700

Hi Roque,

> 	If the router looses connectivity with caches, either by operational issues or by malicious event (on the cache/ the router or the network between the two), the set of prefixes that should be "val…

Does the following suffice for the security considerations section? Note the added sentence in emphasis  "_Similarly..."

   Although this specification discusses one portion of a system to
   validate BGP routes, it should be noted that it relies on a database
   (RPKI or other) to provide validation information.  As such, the
   security properties of that database must be considered in order to
   determine the security provided by the overall solution.  If
   "invalid" routes are blocked as this specification suggests, the
   overall system provides a possible denial-of-service vector, for
   example if an attacker is able to inject one or more spoofed records
   into the validation database which lead a good route to be declared
   invalid.  _Similarly, if the connection to the cache is lost for whatever
   reason, the integrity of the database is no longer maintained. This
   may result in undesired behavior._ In addition, this system is only able 
   to provide limited protection against a determined attacker -- the 
   attacker need only prepend the "valid" source AS to a forged BGP 
   route announcement in order to defeat the protection provided by  
   this system.  This mechanism does not protect against "AS in the 
   middle attacks" or provide any path validation.  It only attempts to 
   verify the origin. In general, this system should be thought of more 
   as a protection against misconfiguration than as true "security" in 
   the strong sense.

Thanks,
- Pradosh

---

From: Roque Gagliano <[email-masked]>
Date: Mon, 22 Aug 2011 13:15:36 +0200

Hi Pradosh,

> Does the following suffice for the security considerations section? Note the added sentence in emphasis  "_Similarly..."

Yes, looks good.

Roque