*> 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 ? *> 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. r. On Mon, Mar 18, 2019 at 10:22 AM Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email protected]> wrote: > *Hi Robert,* > > > > *Please see inline.* > > > > > > *From:* Robert Raszuk [mailto:[email protected]] > *Sent:* Saturday, March 16, 2019 7:38 AM > *To:* Guyunan (Yunan Gu, IP Technology Research Dept. NW) < > [email protected]> > *Cc:* [email protected]; Brian Dickson <[email protected]> > *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) <[email protected]> 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:[email protected]] *On Behalf Of *Robert Raszuk > *Sent:* Thursday, March 14, 2019 5:31 PM > *To:* Brian Dickson <[email protected]> > *Cc:* [email protected] > *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 < > [email protected]> 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 <[email protected]> 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 <[email protected]> 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/grow > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
