Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt
*> It’s capable of detecting the cases where the local AS is placed in the
incorrect place of the AS-PATH*
Such feature has been build into all BGP stacks for ages ... it is called
"enforce-first-as".
Moreover there are BGP policies explicitly allowing you to place your local
AS anywhere in the AS-PATH.
See RPL knob: "replace as-path {[as-number-list] [parameter] | private-as}"
So I am not sure what really does your draft is attempting to
innovate/propose.
Best,
R.
r.
On Fri, Mar 15, 2019 at 11:03 AM Guyunan (Yunan Gu, IP Technology Research
Dept. NW) wrote:
> *Hi Robert,*
>
>
>
> *As stated in this draft, we only check the peering relationship between
> the local AS and it left/right AS as listed in the AS-PATH. Such peering
> relationship is maintained at the local database in whatever form. It’s
> capable of detecting the cases where the local AS is placed in the
> incorrect place of the AS-PATH, however it’s not capable of detecting other
> types of forged AS-PATHs (e.g., an extra AS1000 is inserted into the path).
> Although it only covers limited cases, it doesn’t require third-party
> information or inference. *
>
>
>
> *Agree that with a public and accurate database for a comprehensive check
> of the whole AS path, more cases can be detected. However, the building of
> such database still requires non-trivial work. *
>
>
>
>
>
> *Yunan*
>
>
>
> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, March 14, 2019 5:31 PM
> *To:* Brian Dickson
> *Cc:* grow@ietf.org
> *Subject:* Re: [GROW] I-D Action:
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
> Hi Brian,
>
>
>
> Yes CAIDA has been an excellent source of data and tools for anyone
> concerned about Internet topology or BGP operation.
>
>
>
> It can also accurately detect a lot of anomalies and report them based on
> the comparison of historical data vs real time data (for example ARTEMIS)..
>
>
>
> But the proposed here mechanism compares in real time BGP updates to an
> oracle database for AS-PATH content accuracy. So any data which is based on
> AS-PATHs itself (to create the relations) I am afraid can not be used as
> such baseline src to validate AS-PATHs correctness.
>
>
>
> Thx a lot,
> R.
>
>
>
>
>
>
>
> On Thu, Mar 14, 2019 at 1:20 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
> CAIDA has lots of data sets, tools, etc.
>
>
>
> Here's one of the README files I grabbed, with some URLs that would help
> you find the specifics, and reference materials (papers) on what/why/how
> they are able to infer these relationships.
>
>
>
> Brian
>
>
>
> The 'serial-2' directory contains AS relationships that combine the
>
> 'serial-1' AS relationships (inferred using the method described in
>
> "AS Relationships, Customer Cones, and Validation" published in
>
> IMC 2013, http://www.caida.org/publications/papers/2013/asrank/),
>
> with AS relationships inferred from Ark traceroutes, and from
>
> multilateral peering
>
> (
> http://www.caida.org/publications/papers/2013/inferring_multilateral_peering/
> ).
>
>
>
> To do this we first infer which AS owns each router independent of the
>
> interface addresses observed at that router. The ownership inferences
>
> are based on IP-to-AS mapping derived from public BGP data, list of
>
> peering prefixes from PeeringDB, and the previously inferred business AS
>
> relationships. Then we convert the observed IP path into an AS path
>
> using the router ownership information (rather than mapping each
>
> observed IP to AS directly) and retain the first AS link in the
>
> resulting path for the AS graph.
>
>
>
> The as-rel files contain p2p and p2c relationships. The format is:
>
> ||-1
>
> ||0|
>
>
>
>
>
> Acceptable Use Agreement
>
>
>
>
>
> The AUA that you accepted when you were given access to these datas is
> included
>
> in pdf format as a separate file in the same directory as this README file.
>
> When referencing this data (as required by the AUA), please use:
>
>
>
> The CAIDA AS Relationships Dataset,
>
> http://www.caida.org/data/active/as-relationships/
>
>
>
> Also, please, report your publication to CAIDA
>
> (http://www.caida.org/data/publications/report-publication.xml).
>
>
>
> On Mon, Mar 11, 2019 at 4:48 PM Robert Raszuk wrote:
>
> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>
>
>
> The draft says:
>
>
>
> " At this point, AS 200 *can lookup the local resource database* and
>
>check whether there is a real AS relationship between the local AS
>
>and the left AS and the right AS"
>
>
>
> Can you please share a pointer to any database or accurate public oracle
> where anyone could check if peering relation found in the AS-PATH is valid
> or invalid ?
>
>
>
> Just over the last few months I connected my AS to number of Tier1 ISPs in
> few of my experimental POPs, but never reported that peering establishment
> to anyone. Then I have a que
Re: [GROW] I-D Action: draft-ietf-grow-rpki-as-cones-00.txt
Hi, A few comments on the draft. > A policy definition contains a list the upstream and peering I think 'of' is missing, but still the paragraph is not easy to parse. > 2. If there is no specific definition for the relationship, the >ASX:Default policy; When you say ASX:Defaul, are you referring to the "The default behaviour for a neighbour, if the relationship is not explicitly described in the policy" mentioned before? To avoid ambiguity you may want to introduce this notation there. > 3. Validating an AS-Cone > If the validated cache does not contain the referenced object, >then the validation moves on to the next downstream ASN; Meaning routes originated by this ASN will be rejected (or a filter won't contain these routes)? Better to be explicit about this. > 2. If there is a reference to another AS-Cone, the validating >process should recursively process all the entries in that >AS-Cone first, with the same principles contained in this >list. Here is a question. As I understand, the policy definition object is intended to allow a customer to indicate to the upstream which AS-Cone to use (and which prefixes to expect). The customer controls this policy. However, the reference to an AS-Cone in another AS-Cone seems to be done at will of a provider, based on some static decision, rather than the analysis of a corresponding policy definition. Do you think that can lead to inconsistencies? Thanks, Andrei signature.asc Description: OpenPGP digital signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt
Hi Robert, As stated in this draft, we only check the peering relationship between the local AS and it left/right AS as listed in the AS-PATH. Such peering relationship is maintained at the local database in whatever form. It’s capable of detecting the cases where the local AS is placed in the incorrect place of the AS-PATH, however it’s not capable of detecting other types of forged AS-PATHs (e.g., an extra AS1000 is inserted into the path). Although it only covers limited cases, it doesn’t require third-party information or inference. Agree that with a public and accurate database for a comprehensive check of the whole AS path, more cases can be detected. However, the building of such database still requires non-trivial work. Yunan From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, March 14, 2019 5:31 PM To: Brian Dickson Cc: grow@ietf.org Subject: Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt Hi Brian, Yes CAIDA has been an excellent source of data and tools for anyone concerned about Internet topology or BGP operation. It can also accurately detect a lot of anomalies and report them based on the comparison of historical data vs real time data (for example ARTEMIS). But the proposed here mechanism compares in real time BGP updates to an oracle database for AS-PATH content accuracy. So any data which is based on AS-PATHs itself (to create the relations) I am afraid can not be used as such baseline src to validate AS-PATHs correctness. Thx a lot, R. On Thu, Mar 14, 2019 at 1:20 AM Brian Dickson mailto:brian.peter.dick...@gmail.com>> wrote: CAIDA has lots of data sets, tools, etc. Here's one of the README files I grabbed, with some URLs that would help you find the specifics, and reference materials (papers) on what/why/how they are able to infer these relationships. Brian The 'serial-2' directory contains AS relationships that combine the 'serial-1' AS relationships (inferred using the method described in "AS Relationships, Customer Cones, and Validation" published in IMC 2013, http://www.caida.org/publications/papers/2013/asrank/), with AS relationships inferred from Ark traceroutes, and from multilateral peering (http://www.caida.org/publications/papers/2013/inferring_multilateral_peering/). To do this we first infer which AS owns each router independent of the interface addresses observed at that router. The ownership inferences are based on IP-to-AS mapping derived from public BGP data, list of peering prefixes from PeeringDB, and the previously inferred business AS relationships. Then we convert the observed IP path into an AS path using the router ownership information (rather than mapping each observed IP to AS directly) and retain the first AS link in the resulting path for the AS graph. The as-rel files contain p2p and p2c relationships. The format is: ||-1 ||0| Acceptable Use Agreement The AUA that you accepted when you were given access to these datas is included in pdf format as a separate file in the same directory as this README file. When referencing this data (as required by the AUA), please use: The CAIDA AS Relationships Dataset, http://www.caida.org/data/active/as-relationships/ Also, please, report your publication to CAIDA (http://www.caida.org/data/publications/report-publication.xml). On Mon, Mar 11, 2019 at 4:48 PM Robert Raszuk mailto:rob...@raszuk.net>> wrote: Dear authors of draft-chen-grow-enhanced-as-loop-detection, The draft says: " At this point, AS 200 can lookup the local resource database and check whether there is a real AS relationship between the local AS and the left AS and the right AS" Can you please share a pointer to any database or accurate public oracle where anyone could check if peering relation found in the AS-PATH is valid or invalid ? Just over the last few months I connected my AS to number of Tier1 ISPs in few of my experimental POPs, but never reported that peering establishment to anyone. Then I have a question - how any (public) database would accurately reflect any global BGP peering relation to be used anywhere for filtering of BGP updates ? Kind regards, RR. On Tue, Mar 12, 2019 at 12:27 AM mailto:internet-dra...@ietf.org>> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhanced AS-Loop Detection for BGP Authors : Huanan Chen Yunan Gu Shunwan Zhuang Haibo Wang Filename: draft-chen-grow-enhanced-as-loop-detection-00.txt Pages : 9 Date: 2019-03-11 Abstract: This document proposes to enhance AS-Loop Detection for BGP Inbound/ Outbound Route Processing. The IETF datatracker status page for this draft is: https://data
