Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

[Jakob Heitz <[e-mail]>]

On Tuesday, May 29, 2012 5:52 PM, Randy Bush <mailto:[e-mail]> wrote:

>>> and here i thought that detecting that they differ, as an attack, is
>>> the core goal of as-path validation.
>> I thought it was to prevent an AS from announcing an update that it
>> was not authorised to.
> 
> nope.  that is rpki-based origin validation.  we are now talking about
> as-path validation.
> 
> from a note to some gov folk:
> 
> To be clear, as people keep calling BGP security 'RPKI'
> 
> In the current taxonomy, there are three pieces, the RPKI, RPKI-based
> origin validation, and then path validation.
> 
> RPKI is the X.509 based hierarchy with is congruent with the internet
> IP address allocation administration, the IANA, RIRS, ISPs, ...  It
> is the substrate on which the next two are based.  It is currently
> deployed in four of the five administrative regions, ARIN in North
> America being the sad and embarrassing exception.
> 
> RPKI-based origin validation uses some of the RPKI data to allow a
> router to verify that the autonomous system announcing an IP address
> prefix is in fact authorized to do so.  This is not crypto checked so
> can be violated.  But it prevents the vast majority of accidental
> 'hijackings' on the internet today, e.g. the famous Pakastani
> accidental announcement of YouTube's address space.  RPKI-based
> origin validation 
> is in shipping code from Cisco, and will be shipping by Juniper soon.
> 
> Path validation uses the full crypto information of the RPKI to make
> up for the embarrassing mistake that, like much of the internet BGP
> was designed with no thought to securing the BGP protocol itself from
> being gamed/violated.  It allows a receiver of a BGP announcement to
> formally cryptographically validate that the originating autonomous
> system was truely authorized to announce the IP address prefix, and
> that the 
> systems through which the announcement passed were indeed those which
> the sender/forwarder at each hop intended.
> 
> Sorry to drone on, but these three really need to be differentiated.
> 
> randy

Apology accepted.
Note, I said "announcing", not "originating".

Here is my view of the difference:

Origin validation does not stop anyone from announcing an update.
It only requires the first AS in that update to be the
owner of the prefix.

Path validation prevents anyone from announcing an update unless
it was sent to them by an authorised AS. And they are authorised,
because it was sent to them by an authorised AS and so on, back
to the authorised originator.

-- 
Jakob Heitz.