From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Monday, March 18, 2019 6:05 PM To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyu...@huawei.com> Cc: grow@ietf.org; Brian Dickson <brian.peter.dick...@gmail.com> Subject: Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt
> In the BGP Update received from the eBGP peer, the eBGP peer has already > placed the local AS number in the > AS-PATH. Thus, the device needs to analyze if the local AS is placed > improperly in the AS-PATH when it receives > the Update. How is this different from basic AS-PATH loop detection done by any real BGP speaker today ? Yunan: To the best of my knowledge, currently when an as loop is detected, the message is simply dropped without further analysis. If using the proposed inbound check, possible hijack can be detected. > this Update is not allowed to be advertised to this downstream AS. We > propose to do an outbound check > enhancement for such advertisement failure. That is default behavior already in number of shipping BGP implementations. In some other it depends on the update/peer group configuration. Yunan: Similarly, currently when the split-horizon is enabled and the described case is detected, the message is again simply dropped without further analysis. If using the proposed outbound check, possible hijack can be detected. r. On Mon, Mar 18, 2019 at 10:22 AM Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyu...@huawei.com<mailto:guyu...@huawei.com>> wrote: Hi Robert, Please see inline. From: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>] Sent: Saturday, March 16, 2019 7:38 AM To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyu...@huawei.com<mailto:guyu...@huawei.com>> Cc: grow@ietf.org<mailto:grow@ietf.org>; Brian Dickson <brian.peter.dick...@gmail.com<mailto:brian.peter.dick...@gmail.com>> Subject: 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". Yunan: The BGP “enforce-first-as” is used to check if the incoming updates received from eBGP peers have their AS number as the first segment in the AS_PATH attribute. It’s not used to check the local AS placement. 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}" Yunan: Yes, prepending the local AS by the local device in specific places of the AS-PATH is allowed. But here we are discussing the local AS placement by other devices: In the BGP Update received from the eBGP peer, the eBGP peer has already placed the local AS number in the AS-PATH. Thus, the device needs to analyze if the local AS is placed improperly in the AS-PATH when it receives the Update. This is the inbound check enhancement we propose in the draft. So I am not sure what really does your draft is attempting to innovate/propose. Yunan: We also proposed the outbound check enhancement: Due to misconfiguration or attack in the local device or upstream BGP speaker mistake/hijack, the neighboring downstream AS is already placed in the AS-PATH. Thus with the Split-Horizon enabled, this Update is not allowed to be advertised to this downstream AS. We propose to do an outbound check enhancement for such advertisement failure. Best, R. r. On Fri, Mar 15, 2019 at 11:03 AM Guyunan (Yunan Gu, IP Technology Research Dept. NW) <guyu...@huawei.com<mailto:guyu...@huawei.com>> 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<mailto:grow-boun...@ietf.org>] On Behalf Of Robert Raszuk Sent: Thursday, March 14, 2019 5:31 PM To: Brian Dickson <brian.peter.dick...@gmail.com<mailto:brian.peter.dick...@gmail.com>> Cc: grow@ietf.org<mailto: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<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: <provider-as>|<customer-as>|-1 <peer-as>|<peer-as>|0|<source> ------------------------ 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, <date range used> 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 <rob...@raszuk.net<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 <internet-dra...@ietf.org<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://datatracker.ietf...org/doc/draft-chen-grow-enhanced-as-loop-detection/<https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/> There are also htmlized versions available at: https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00 https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ GROW mailing list GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
