Re: [GROW] [Sidrops] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?
Hi all, The current version of the draft follows the wording from draft-ietf-idr-deprecate-as-set-confed-set BGP speakers conforming to this document (i.e., conformant BGP speakers) MUST NOT locally generate BGP UPDATE messages containing AS_SET or AS_CONFED_SET. Conformant BGP speakers SHOULD NOT send BGP UPDATE messages containing AS_SET or AS_CONFED_SET. Upon receipt of such messages, conformant BGP speakers SHOULD use the "Treat-as- withdraw" error handling behavior as per [RFC7606 <https://datatracker.ietf.org/doc/html/rfc7606>]. As you can see, it uses 'SHOULD'. And this was the reason to have an additional 'Unverifiable' state, because the 'Invalid' routes MUST be rejected. If the WG agrees to change normalative language from 'SHOULD' to 'MUST', the ASPA document will follow. вс, 24 июл. 2022 г. в 11:53, Sriram, Kotikalapudi (Fed) < kotikalapudi.sri...@nist.gov>: > I think we can conclude that the outcome of the discussions in this thread > is to make the following change in ASPA-based AS path verification: > > If an AS_PATH has one or more AS_SETs in any position, mark it as Invalid. > > At least four (perhaps all five) of us who participated in the discussion > support this change. > > Thanks. > > Sriram -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] AD Review of draft-ietf-idr-bgp-open-policy-15
Dear Alvaro, Thank you for your detailed comments. I will work on the edits during the weekend and after recheck in our small co-author group, I'll push the next version. May I ask you to give more details on this part of your comment? > Also, I believe the specification is not complete. Can you amplify what parts of mechanics are missing? ср, 9 июн. 2021 г. в 22:40, Alvaro Retana : > Dear authors: > > Thank you for your work on addressing the route leaks problem! > > I think the document still needs a lot of work. In general, the > precision in the language is not what I would expect from a Standards > Track document. Also, I believe the specification is not complete. > Please see details inline. > > Instead of returning the document to the WG, and because it is short, > I am including a long list of suggestions below. Given all the > proposed changes, we will eventually need to run a new WGLC explicitly > including the grow WG -- I have cc'd them in this message as well. > > > Thanks! > > Alvaro. > > > [Line numbers from idnits.] > > > ... > 14 Route Leak Prevention using Roles in Update and Open messages > 15 draft-ietf-idr-bgp-open-policy-15 > > [minor] s/Update and Open/UPDATE and OPEN BGP > > > [major] Throughout the document the concept of "sending prefixes" (or > sometimes announcing them) is used -- I understand that these are > common phrases. However, that is not the terminology used in rfc4271. > Please use "route advertisement" (and variations) instead. Note that > "propagated" is also ok. > > > 17 Abstract > > 19 Route leaks are the propagation of BGP prefixes which violate > 20 assumptions of BGP topology relationships; e.g. passing a route > 21 learned from one lateral peer to another lateral peer or a > transit > 22 provider, passing a route learned from one transit provider to > 23 another transit provider or a lateral peer. Existing > approaches to > 24 leak prevention rely on marking routes by operator > configuration, > 25 with no check that the configuration corresponds to that of the > eBGP > 26 neighbor, or enforcement that the two eBGP speakers agree on the > 27 relationship. This document enhances BGP OPEN to establish > agreement > 28 of the (peer, customer, provider, Route Server, Route Server > client) > 29 relationship of two neighboring eBGP speakers to enforce > appropriate > 30 configuration on both sides. Propagated routes are then marked > with > 31 an Only to Customer (OTC) attribute according to the agreed > 32 relationship, allowing both prevention and detection of route > leaks. > > [minor] > > OLD> >This document enhances BGP OPEN to establish agreement of the (peer, >customer, provider, Route Server, Route Server client) relationship of >two neighboring eBGP speakers to enforce appropriate configuration on > both >sides. Propagated routes are then marked with an Only to Customer (OTC) >attribute according to the agreed relationship, allowing both prevention >and detection of route leaks. > > Suggestion> >This document enhances the BGP OPEN message to establish an agreement of >the relationship between two eBGP speakers in order to enforce > appropriate >configuration on both sides. Propagated routes are then marked > according >to the agreed relationship, allowing both prevention and detection of > route >leaks. > > > ... > 94 1. Introduction > > 96 A BGP route leak occurs when a route is learned from a transit > 97 provider or lateral peer and then announced to another provider > or > 98 lateral peer. See [RFC7908]. These are usually the result of > 99 misconfigured or absent BGP route filtering or lack of > coordination > 100between two eBGP speakers. > > [nit] s/peer. See [RFC7908]./peer [RFC7908]. > > > [nit] s/between two eBGP speakers./between autonomous systems. > > > 102The mechanism proposed in > 103[I-D.ietf-grow-route-leak-detection-mitigation] uses large- > 104communities to perform detection and mitigation of route leaks. > 105While signaling using communities is easy to implement and > deploy > 106quickly, it normally relies on operator-maintained policy > 107configuration, which is vulnerable to misconfiguration > [Streibelt]. > 108The community signal can also be stripped at the ISP boundaries -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [WG ADOPTION]: draft-mcbride-grow-as-path-prepend-01 - ENDS 08/12/2020 (Aug 12)
I support adoption as WG item. чт, 30 июл. 2020 г. в 09:13, Pedro Andres Aranda Gutierrez < paag...@gmail.com>: > +1 > > On Thu, 30 Jul 2020 at 06:13, Brian Dickson > wrote: > >> Support adoption as a WG item. Willing to contribute text, reviews, etc. >> >> Brian >> >> On Wed, Jul 29, 2020 at 10:17 AM Christopher Morrow < >> christopher.mor...@gmail.com> wrote: >> >>> Howdy WG Folks! >>> There's been significant chatter on-list about: >>> draft-mcbride-grow-as-path-prepend-01 >>> >>> Abstract: >>> "AS_Path prepending provides a tool to manipulate the BGP AS_Path >>>attribute through prepending multiple entries of an AS. AS_Path >>>prepend is used to deprioritize a route or alternate path. By >>>prepending the local ASN multiple times, ASes can make advertised AS >>>paths appear artificially longer. Excessive AS_Path prepending has >>>caused routing issues in the internet. This document provides >>>guidance,to the internet community, with how best to utilize AS_Path >>>prepend in order to avoid negatively affecting the internet." >>> >>> This work seems directly in the GROW wheelhouse, and it appears folk >>> on-list agree. Let's decide with a WG Adoption call for this document >>> and see if we should continue this work officially/etc. >>> >>> Please give it a read, and comment on adoption ideals here-in. >>> >>> thanks! >>> -chris >>> co-chair-persona >>> >>> ___ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >>> >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> > > > -- > Fragen sind nicht da um beantwortet zu werden, > Fragen sind da um gestellet zu werden > Georg Kreisler > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Call for IETF 106 agenda items
Hi all, I would like to reserve 10 minutes to talk about max length in ROV. ср, 23 окт. 2019 г. в 20:07, Camilo Cardona : > Hi Job, > > We would like to have a couple of minutes for > draft-cppy-grow-bmp-path-marking-tlv. > > Thanks, > Camilo > > > On 22 Oct 2019, at 17:56, Job Snijders wrote: > > > > Dear Folks! > > > > GROW is planning to meet in Singapore at IETF 106, iff we have agenda > > items. People who would like time on the agenda please send a request so > > that a time slot and agenda can be prepared! > > > > Presentation proposals with drafts will have priority over talks without > > an uploaded draft. > > > > Kind regards, > > > > Job > > > > ___ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow > > _______ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-route-leak-detection-mitigation-01.txt
Dear WG, I'd like to highlight, that the WGLC for the draft-ietf-grow-route-leak-detection is still locked by the absence of reserved class for well-known transit communities. If somebody is already working on this specification - please raise your hand. Otherwise, I will be using my Russian-English to wright this spec. You are warned. пт, 26 июл. 2019 г. в 20:11, Alexander Azimov : > Dear WG, > > This document of route leak detection using communities seems to address > all unresolved issues from the previous versions. > We believe that the proposed solution can be easily adopted by the ISPs > thus reducing the number of route leaks that become globally propagated. > > There is one unresolved dependency - we need IANA to reserve a class for > well-known transit communities. > As far as I remember that there was already some work in this field. I'm > eager to assist if this can help to speed up the process. > > пт, 26 июл. 2019 г. в 20:02, : > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Global Routing Operations WG of the IETF. >> >> Title : Methods for Detection and Mitigation of BGP >> Route Leaks >> Authors : Kotikalapudi Sriram >> Alexander Azimov >> Filename: >> draft-ietf-grow-route-leak-detection-mitigation-01.txt >> Pages : 9 >> Date: 2019-07-26 >> >> Abstract: >>Problem definition for route leaks and enumeration of types of route >>leaks are provided in [RFC7908]. This document describes a new well- >>known Large Community that provides a way for route leak prevention, >>detection, and mitigation. The configuration process for this >>Community can be automated with the methodology for setting BGP roles >>that is described in ietf-idr-bgp-open-policy draft. >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/ >> >> There are also htmlized versions available at: >> >> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-01 >> >> https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-01 >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-route-leak-detection-mitigation-01 >> >> >> 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/ >> >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> > > > -- > Best regards, > Alexander Azimov > -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-route-leak-detection-mitigation-01.txt
Dear WG, This document of route leak detection using communities seems to address all unresolved issues from the previous versions. We believe that the proposed solution can be easily adopted by the ISPs thus reducing the number of route leaks that become globally propagated. There is one unresolved dependency - we need IANA to reserve a class for well-known transit communities. As far as I remember that there was already some work in this field. I'm eager to assist if this can help to speed up the process. пт, 26 июл. 2019 г. в 20:02, : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations WG of the IETF.. > > Title : Methods for Detection and Mitigation of BGP > Route Leaks > Authors : Kotikalapudi Sriram > Alexander Azimov > Filename: > draft-ietf-grow-route-leak-detection-mitigation-01.txt > Pages : 9 > Date: 2019-07-26 > > Abstract: >Problem definition for route leaks and enumeration of types of route >leaks are provided in [RFC7908]. This document describes a new well- >known Large Community that provides a way for route leak prevention, >detection, and mitigation. The configuration process for this >Community can be automated with the methodology for setting BGP roles >that is described in ietf-idr-bgp-open-policy draft. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/ > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-01 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-route-leak-detection-mitigation-01 > > > 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/ > > _______ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Possible Next Version of route-leak-detection-mitigation
Hi Jeff, пн, 8 июл. 2019 г. в 22:22, Jeffrey Haas : > Alexander, > > On Mon, Jul 08, 2019 at 06:06:15PM +0300, Alexander Azimov wrote: > >- A single community is used for both route leak prevention, and > >detection; > >- All route leaks MUST be rejected; > >- L is removed since we don't need it in this case. > > A default policy of reject all leaks makes sense, I think. > > I have a slightly different view of what has been called L above: > Programmatically determining that you are the network of last resort to not > cut off an ASes prefix is tricky. This is what the NOC phones get used > for. > > What's somewhat desired, I think, is dealing with the result of that NOC > phone call: An attestation that a provider has permitted a detected leak. > Consider it an "override". > If you are already calling it's better to call not the upper upstream provider who dropped the leak, but the 'intermediate' provider who accepted the leak. Anyway, I'm planning to have another topology study and check how many prefixes may be theoretically affected with such anomaly. > An aside question: For service providers that are "peer" types, how are > their own internal networks intended to be flagged? > If I got your question correctly, there is no marking (or no additional marking) before prefix is sent to 'external' neighbor. It is also true for networks with multiple ASNs under control. -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation
Hi all, My attitude for this draft has changed several times, so did for communities vs attributes. But my current opinion can't be explained if I speak solely about this draft. There are three sets of documents that are related to detection and mitigation of mistakes/malicious activity that may happen at the interdomain routing level. - Roles + iOTC: leak prevention, makes configuration quite easier for small-medium networks. Adopted, nearly ready for WGLC, will take years to deploy widely. - ASPA: detection of mistake/malicious activity using RPKI objects. Adopted, active work on the draft, will take years to deploy widely (RIRs a major concern). - Leak detection using community. Adopted, the draft needs significant document restructure and clarification before WGLC. The main advantage of this work and usage of communities:* it can be deployed now *(at least in networks that do support large communities). That's why I made a commitment to do my best in assisting with text. The current goal - prepare it to WGLC it before meeting in Montreal. сб, 15 июн. 2019 г. в 13:23, Nick Hilliard : > Brian Dickson wrote on 15/06/2019 00:42: > > Please take a look and, if you think this is an important problem to fix > > (route leaks), add your voice here. > > there are two things here: route leaks (important), and the proposal in > draft-ietf-grow-route-leak-detection-mitigation. We can probably all > agree that route leaks are a persistent threat. > > What concerns me about this draft is that it takes an over-simplified > view of real-life networks and there's not a small amount of implied > pigeon-holing going on. The difficult with the draft is that many > networks don't fall into these neatly defined categories. There are > back-doors, partial transit configs, PNI arrangements, subnet leaks and > all sorts of weird things out there, none of which are easy to > categorise, but which nevertheless make up an important part of the > routing ecosystem. > > Characterisation of these edge cases is a difficult problem. I'm not > convinced this can be done adequately without an expressive grammar > (note: not rpsl). I'm also not convinced that the approach taken in > draft-ietf-grow-route-leak-detection-mitigation is generic enough to be > worth deploying. > > Nick > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Route Server ASN stripping hiding considered harmful?
Hi all, I'd like to share my support to Job's position, and the reason isn't only 'transparency' or filtering (while they are worth to fight for). I see as the core of the problem, that one ISP MUST add its AS Number in the AS_PATH and another ISP is permitted no to do it. Yes, one can tell me, that IXP doesn't provide transit, it provides only local connectivity, through L2 matrix, but does ISP becomes IXP if it provides local connectivity? Imagine a situation when a customer has a choice: to purchase partial transit (only customer cone) from ISP or to become a member of IX. The price for both services could be quite comparable, but customer is looking forward not only for lesser costs, but also for increase its margin, and even if ISP will have all IX members as customers, it will be less preferable because through IX the path will have -1 hop. Some ISPs are already asking themselves a question, maybe they can also remove their AS number, at least when announcing routes to customers? And this pandora box has been already opened, I can name several ISPs that provide transit and remove its ASN from AS_PATH attribute, some of them are removing it even when announcing routes to upstreams. It's not right, it violates BGP loop detection, but it has just same motivation as RS at IXP - to make their routes more preferable, make 'virtual direct' connections. Some of them even name themselves as IXPs. In BGPSec it's getting even worse with pCount = 0. There is a statement in section 7.2.: > if a BGPsec speaker does not expect a peer AS to set its pCount=0 and >if an UPDATE message received from that peer violates this, then the >UPDATE message MUST be considered to be in error (see the list of >checks in Section 5.2). See Section 8.4 for a discussion of security >considerations concerning pCount=0. Well, I can assume that some transit providers will be checking this pCount value, but I don't believe it will be checked from the customer side (it's even impossible for all, except direct neighbor). It can end up with everybody setting pCount=0 and AS_PATH attribute will lose much of its current use cases. 2017-12-18 20:38 GMT+03:00 Nick Hilliard <n...@foobar.org>: > Job Snijders wrote: > > You and Martijn appear to argue that the 'best path selection' > > component should not be fiddled with, which leaves me wondering > > whether we have any other methods to implement a track record ala > > 'this path announcement passed through RS AS XYZ' other than > > communities. Or are you of the opinion that the lack of visibility is > > not a problem to begin with? > > communities are low-hanging fruit and non-intrusive, and probably not a > bad thing to do. > > If you plan to spend time and energy dealing with the underlying > problem, i.e. routing leaks, then I'd suggest continuing to work on > getting IXPs to implement prefix filtering on their route servers. It's > laborious and thankless but will actually fix the problem in the longer > term - and it needs to be done anyway. > > Nick > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: a...@qrator.net | visit: www.qrator.net ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] working group last call draft-ietf-grow-bgp-gshut
I've read this draft and support its publication. Special thanks for those who had resolved my concerns about possible side effects of this new well-known community. 2017-07-24 18:13 GMT+03:00 Peter Schoenmaker <p...@lugs.com>: > Hi Grow, > > > > As discussed in the working group meeting in Prague, draft-ietf-grow-bgp-gshut > is ready for last call. The last call will be 3 weeks ending August 11th > 2017. Please review the document and provide feedback. > > > > The document is at https://datatracker.ietf.org/ > doc/draft-ietf-grow-bgp-gshut/ > > > > Thanks > > > > Peter & Chris > > > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: a...@qrator.net | visit: www.qrator.net ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
