From benm at workonline.co.za  Wed Jun 22 11:09:59 2016
From: benm at workonline.co.za (Ben Maddison)
Date: Wed, 22 Jun 2016 15:09:59 +0000
Subject: [Secbgp] Path Validation Design Thoughts
Message-ID: <874E439F335FD742B8D1565730E537E0D89CDD91@ex1.workonline.co.za>

Hi all,

Thanks to everyone who made time for our lunch meeting last week.
As promised, at long last, I've taken some time to flesh out my thinking on a (hopefully) sensible approach to the path validation problem.

This is all from my perspective, which is that of a non-transit-free IP transit provider. I'm sure that others will have different considerations, and I'm particularly interested to hear where these lead to other conclusions on the below.
This is going to be a long email: please accept my apologies in advance ;-)

My starting-off question is one that we haven't really discussed explicitly: what do we mean when we say an AS_PATH attribute is "valid"?
There seem to be two possible answers to this:

1.    The NLRI really was propagated in BGP across the indicated list of ASs; or

2.    The announcement of the NLRI at a given adjacency is consistent with the policies (evaluated right to left) of the ASs in the path.
Neither one of these necessarily implies the other, at least without additional assumptions.

The semantics of the model that we've been discussing are roughly (and please chime in if I'm misrepresenting this):

-       I'm seeing path 65000_65001_65002; and

-       I have been reliably informed that the adjacencies (65000,65001) (65001,65002) exist; so

-       Therefore I can be reasonably assured that the announcement was propagated across that path.
These semantics can be used to build a DAG of AS connectivity which is then used to provide a reasonable answer to #1.
Statements of policy can then be overlaid to indicate restrictions on what should be visible across a given adjacency (e.g. to indicate a no-transit valley, etc). If this policy information is reasonably complete, then it can provide an answer to #2.

For our purposes, as a relying party, all I really care about is #2 - i.e. should this peer be announcing transit to me for these downstream networks?
The existence of non-transit adjacencies in an AS connectivity DAG are irrelevant for the purposes of this question. In fact, it seems to me that the visibility of non-transit adjacencies in the graph may simply confuse the validation process, as that requires an answer to the question of whether the absence of a non-transit policy is the result of act or omission.

If (and I recognize that is a big "if") the primary semantic is one of edges in a directed graph that are authorized to announce transit, then the next issue becomes, what is the source of truth for that authorization?
Randy stated, in response to Russ's presentation in San Diego, that source of authority in this context ought to be the registrant of the address space. This is of course the case in the context of origin validation, but makes no sense in the context of path validation. The scope of routing policy in BGP is (by design, if sometimes not in practise) the AS, and thus it seems sensible that the AS holder should be the source of truth for statements regarding policy.
My next points are best illustrated by way of example. Let's say that AS65000 receives a prefix from AS65001 with the AS_PATH 65001_65002_65003.
I'd suggest that the validation of this path should be something like:

if AS65003 A>> AS65002 then
  if AS65002 A>> AS65001 then
    accept
  else
    if AS65001 <<A AS65000 then
      accept
    else
      reject
    fi
  fi
else
  if AS65001 <<A AS65000 then
    if AS65002 <<A AS65001 then
      accept
    else
      reject
    fi
  else
    reject
  fi
fi

Where the "A" operators mean:
            X A>> Y     means that X authorizes Y to announce transit for X to Y's peers; and
            X <<A Y     means that X authorizes Y to announce transit for any prefix (validly) received from Y's peers to X
In the case of a "normal" customer (X)/provider (Y) relationship, this is two halves of the same coin, but more complex policies can be expressed by separating them.
Also, authorizations of the "A>>" type will need to be globally visible to relying parties, whilst authorizations of type "<<A" need only be available to the authorizing AS's customer cone.
One immediate political benefit is that providers need make no attestations regarding whether a given AS is a customer. In fact, a transit-free network need do nothing whatever.

If we wanted to, reusing the RPKI for the above would be straightforward. An "LOA" object would be created and published in the local repo, just as ROAs are for origin validation, except that the signer's right to the ASN (rather than the address space) in question would determine the validity of the object. The rtr protocol could also be extended to provide the ASBRs with the additional data to build filters, etc.
Similarly, one could create attributes to be included in the aut-num RPSL class which, along with the inclusion of a signature (RPKI based, or otherwise), provides the same information.

My primary concern with this approach is convergence speed. It is important that rapid changes to peering relationships remain possible, and that changes are reflected in the system roughly as quickly as BGP itself converges. For me, this is a good argument for re-using BGP as Russ has outlined. On the other hand, I'm not wild about overloading BGP with every new idea in the world - especially where there is no good reason to re-use the BGP speakers themselves.

I'd be interested to understand whether anyone can see any immediate issues with this approach from a data model perspective, and also how people see this working from the perspective of a practical implantation.
In particular, Job and Jared, please would you share whatever details you have on your IRR+ proposal so that we can see how the two might look together?

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:     +27 (0) 21 200 9000
Mobile:   +27 (0) 82 415 5545
Email:      benm at workonline.co.za<mailto:benm at workonline.co.za>
SIP:          benm at workonline.co.za<sip:benm at workonline.co.za>

[Workonline Communications]<http://www.workonline.co.za/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/secbgp/attachments/20160622/b7d2dd51/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6746 bytes
Desc: image001.jpg
URL: <https://puck.nether.net/pipermail/secbgp/attachments/20160622/b7d2dd51/attachment-0001.jpg>