Question about mutual transit and complex BGP peering
Requesting responses to the following questions. Would be helpful in some IETF work in progress. Q1: Consider an AS peering relationship that is complex (or hybrid) meaning, for example, provider-to-customer (P2C) for one set of prefixes and lateral peers (i.e., transit-free peer-to-peer (P2P)) for another set of prefixes. Are these diverse relationships usually segregated, i.e., P2C on one BGP session and P2P on another? How often they might co-exist within one single BGP session? Q2: Consider an AS peering relationship that is mutual transit (i.e., P2C relationship in each direction for all prefixes). Is this supported within one single BGP session? How often the ASes might setup two separate BGP sessions between them -- one for P2C in one direction (AS A to AS B) and the other for P2C in the opposite direction (AS B to AS A)? Thank you. Sriram Kotikalapudi Sriram, US NIST
Re: AS 3356 (Level 3) -- Community 3356:666
>And it's also nice not to yank the old community in case your customers still
>depend on it, even if you do also support the RFC version as an alias of that
>one.
That seems to be the case. Also, possibly the use of WKC 65535:666 has not
picked up much. We observe that out of a total of 264,557 unique {Prefix, AS
Path, Community = Any:666} seen in a whole day's worth of BGP Updates from
RIPE-RIS (July 15, 2021), only 21 are with 65535:666. See slide 12 here:
https://datatracker.ietf.org/meeting/111/materials/slides-111-grow-bgp-regularextendedlarge-community-analysis-01
(presentation at the IETF 111 GROW meeting last week)
Sriram
AS 3356 (Level 3) -- Community 3356:666
There is an old NANOG thread from 2005 that said AS 3356 (Level 3) were applying 3356:666 to indicate Peer route: https://archive.nanog.org/mailinglist/mailarchives/old_archive/2005-12/msg00280.html Also, see: https://onestep.net/communities/as3356/ Now network operators commonly use ASN:666 for BGP Blackholing Community. (ASN = the operator's AS number) See, for example, https://www.he.net/adm/blackhole.html Does anyone know if AS 3356 has changed how it uses 3356:666? I.e., is it known if they now use it for Blackholing Community? Thank you. Sriram
NIST RPKI Monitor version 2.0
We (NIST) have released a new version of the NIST RPKI Monitor (v2.0): https://www.nist.gov/services-resources/software/nist-rpki-deployment-monitor We are open to adding more features and analyses based on user feedback. Your comments/suggestions are welcome. Thank you. Sriram
Re: AS hijacking (Philosophy, rants, GeoMind)
Mike, >As our canned Email stated, AS2 (and many low digit AS') get hijacked and >often go on to hijack someone's prefix. AS2 (proper) is rarely changed and >the chances of an actual prefix hijack from it is extremely low. > >So as I've asked our peers, I'll ask here: What is expected of us to be good >"Net Citizens" with these hijacks? Thoughts on AS hijack prevention: With RPKI-based route origin validation (ROV), it turns out that incremental solution for prefix hijacking is also an incremental solution for AS hijacking. For example -- assuming Invalid routes will be dropped -- if 70% of the announced prefixes are protected by ROAs, then those 70% prefixes cannot be hijacked with a hijacked AS. (Note: An exception to this is -- a deliberate hijacker can still perform what is called forged-origin hijack [1], i.e., the attacker matches the hijacked prefix with a hijacked AS such that they both belong to the same ROA.) So, the community should keep pushing ahead with ROA and RPKI-based ROV deployments to achieve 100% ROA coverage for announced prefixes and also 100% dropping of Invalid. The above can also be said about “trusted” IRR-based (or IRR+RPKI based) ROV [1]. However, priority should be given to speedup the RPKI/ROA deployment towards full adoption. FYI... Worldwide ROA coverage is currently at 20% for globally routed prefixes. https://rpki-monitor.antd.nist.gov/ Security guidance regarding route objects in IRR, ROAs in RPKI, and ROV deployment can be found here: [1] “Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation,” NIST Special Publication, NIST SP 800-189, December 2019. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf Also, look up: [2] MANRS: https://www.manrs.org/ Thank you. Regards, Sriram
Re: SP 800-189 (Draft), Resilient Interdomain Traffic Exchange
I think Doug has already pointed to this: Email for comments: sp800-...@nist.gov mentioned in the link: https://csrc.nist.gov/publications/detail/sp/800-189/draft We are thankful that many helpful comments/suggestions were received from ISPs, other organizations and individuals earlier on the 1st (initial) public draft. For anyone interested to peruse those comments and authors' responses are compiled here: https://csrc.nist.gov/CSRC/media/Publications/sp/800-189/archive/2018-12-17/documents/NIST.SP.800-189-draft-comments-responses.pdf We are now welcoming comments on 2nd draft. Sriram -- Date: Mon, 28 Oct 2019 16:09:54 -0500 From: Job Snijders ... Dear Douglas, Thanks for sharing the link. This is an impressive effort! Can you share with the group what the best way is to share feedback to effect changes in the document? Is there a difference between just emailing you or are there official channels to be considered? Kind regards, Job
Re: Analysing traffic in context of rejecting RPKI invalids using pmacct
Jay: >When we (as7018) were preparing to begin dropping invalid routes >received from peers earlier this year, that is exactly the kind of >analysis we did. In our case we rolled our own with a two-pass >process: we first found all the traffic to/from invalid routes by a >bgp community we gave them, then outside of our flow analysis tool we >further filtered the traffic for invalid routes which were covered by >less-specific not-invalid routes. What remained was the traffic we >would lose once invalid routes were dropped. Had the pmacct >capability existed at that time, we would have used it. We (NIST) did a detailed analysis of Invalid routes (with Routeviews data) that was presented at IETF 101: https://datatracker.ietf.org/meeting/101/materials/slides-101-sidrops-origin-validation-policy-considerations-for-dropping-invalid-routes-00 See slides 10-13. We tried to drill down on Invalid routes which were covered by less-specific not-invalid routes. We examined questions like: how often does the less-specific route have the same origin AS (OAS) as the Invalid, and, if not, then how frequently is the OAS of the less specific route a transit provider of the OAS of the Invalid route? We plan to update the results periodically. Sriram
Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?
Nusenu, I also found your analysis very interesting and useful. Thanks for that. >What do you think about adding graphs that show the amount of actually >unreachable prefixes and IP space? (prefix where no alternative valid/unknown >announcement exists) I am also part of the NIST BGP team. Doug has already responded with information that we will soon have a new version of the NIST Monitor which will provide the kind of graphs that you requested. As an additional piece of info, I had given a presentation at IETF 101 in which you may find the data in slides 10-13 interesting: https://datatracker.ietf.org/meeting/101/materials/slides-101-sidrops-origin-validation-policy-considerations-for-dropping-invalid-routes-00 It is a snapshot -- takes update data from Routeviews and validates routes using ROAs (see slides 10-13). Then it drills down on Invalid routes to see how many are covered by Valid (V) or NotFound (NF) less specific routes. Then further drills down to see if the origin AS (OAS) in the V/NF less specific route is the same or different compared to the OAS in the Invalid route. In many cases, the answer is yes - same OAS. We also found that when the answer was 'different OAS', then interestingly, in many instances the OAS in the V/NF less specific route was the transit provider of the OAS in the Invalid route! We (together with Job) have a draft in the IETF SIDROPS WG that specifies the details of DISR (Drop Invalid if Still Routable) policy: https://tools.ietf.org/html/draft-sriram-sidrops-drop-invalid-policy-01 DISR policy is basically what we are discussing here: Drop Invalid if a Valid or NotFound less specific route exists. When one designs implementable policy based on this, some nuances are important to consider. The draft and the slides attempt to do that. Sriram
RE: BGP route processing speed
>From: Sebastian Spies [mailto:s+mailinglisten.na...@sloc.de] > >my BSc thesis from 2010 might be relevant to what you are looking for. > >https://drive.google.com/file/d/0B5kLBHCcFJjFZk5RTUtwbUstbm8/view?usp=sharing Thanks, Sebastian. Good study. Your convergence time estimates (e.g. Table 2, p. 38) for route servers are interesting and also consistent with the AMS-IX study in 2012 (the latter in realistic IXP scenarios). But I am still interested in any pointers to BGP router measurements in ISP/provider edge scenarios. Sriram >Sriram, Kotikalapudi (Fed) schrieb: >> I am interested in measurements related to BGP route processing speed >> (i.e. routing engine capacity in terms of routes or updates processed per >> second). >> Folks from AMS-IX did an interesting study in 2012 >> in their Route Server / IXP environment. >> https://ams-ix.net/downloads/ams-ix-route-server-implementations-performance.pdf >> >> >> Are there other measurement studies available >> on this topic, especially in ISP/PE router scenarios, >> including BGP policy processing, best path selection, route filtering, etc.? >> Will appreciate much if you can share some pointers. >> >> Sriram
BGP route processing speed
I am interested in measurements related to BGP route processing speed (i.e. routing engine capacity in terms of routes or updates processed per second). Folks from AMS-IX did an interesting study in 2012 in their Route Server / IXP environment. https://ams-ix.net/downloads/ams-ix-route-server-implementations-performance.pdf Are there other measurement studies available on this topic, especially in ISP/PE router scenarios, including BGP policy processing, best path selection, route filtering, etc.? Will appreciate much if you can share some pointers. Sriram
Re: intra-AS messaging for route leak prevention
This is great...the kind of inputs/insights I was hoping for. Thank you :) Sriram From: Mark Tinka <mark.ti...@seacom.mu> Sent: Wednesday, June 8, 2016 9:24 AM To: nanog-p...@rsuc.gweep.net; Sriram, Kotikalapudi (Fed) Cc: Job Snijders; nanog@nanog.org Subject: Re: intra-AS messaging for route leak prevention On 8/Jun/16 14:48, Joe Provo wrote: > > "There are more routing policies in heavan and earth, Sriram > Than are dreamt of in your draft." > > But in my experience, community tagging is by far the widest > deployment due to the broad support and extent of information > which can be carried. It is useful to note that AS_PATH if > often also involved on egress decisions. Agree. We use BGP communities extensively on all eBGP sessions to identify upstreams, peers, customers, special partners, e.t.c., on the inbound routing policy. Outbound routing policies will depend on the type of neighbor, i.e., upstream, peer, customer, special partner, e.t.c. At any rate, we use communities to determine what routes will be announced to what eBGP neighbor. Those communities will need to match the intended source of the route at some other point in the network. The only time we look at prefix lists is to ensure we send (or accept) nothing longer than a /24 (IPv4) or a /48 (IPv6) to (and from) an eBGP neighbor of any kind. That said, further granularity in the outbound routing policy toward upstreams will allow for transmission of longest-match (/32 IPv4 and /128 IPv6) to support RTBH requirements. This is a co-ordinated routing policy, so it is not harmful to us, our upstreams or the wider Internet. We'd also accept these prefix lengths from BGP customers as part of their standard RTBH capability they get when they buy IP Transit from us; again, highly controlled and co-ordinated to never cause any harm to us, the customer or the wider Internet, while still being 100% functional for the customer. Ultimately, once a routing policy is in place on a specific router, we are never touching that router again as the edge moves around, i.e., customers, peers, special partners, e.t.c., come on-board, move around, e.t.c. This creates natural safe guards against cock-ups, although the goal is always to eliminate cock-ups from the get-go (automation of repetitive provisioning tasks makes this goal easier to attain). Coupled with our insistence on creating matching prefix and AS_PATH filters for all customers (after being checked against the relevant RIR WHOIS database to avoid hijack), we've been fortunate to never be in a position where our network is leaking routes, unintentionally or otherwise. Work continues to further harden this so that it never happens. Mark.
Re: intra-AS messaging for route leak prevention
Thanks for the inputs about the inter-AS messaging and route-leak prevention techniques between neighboring ASes. Certainly helpful information and also useful for the draft (draft-ietf-idr-route-leak-detection-mitigation). However, my question was focused on "intra-AS" messaging. About conveying from ingress to egress router (within your AS), the info regarding the type of peer from which the route was received at ingress. This info is used at the egress router to avoid leaking a route. Question: Is the "common practice" described in the original message http://mailman.nanog.org/pipermail/nanog/2016-June/086242.html (see the stuff in quotes) sufficient or are there other ways in common use in which network operators convey the said information from ingress to egress router? Sriram
intra-AS messaging for route leak prevention
I am a co-author on a route-leak detection/mitigation/prevention draft in the IDR WG in the IETF: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03 Based on private conversations with a few major ISPs, the following common practice for intra-AS messaging (using Community tagging in iBGP) for prevention of route leaks is described in Section 3.2 of the draft: “Routes are tagged on ingress to an AS with communities for origin, including the type of eBGP peer it was learned from (customer, transit-provider or peer), geographic location, etc. The community attributes are carried across the AS with the routes. Routes that the AS originates directly are tagged with similar origin communities when they are redistributed into BGP from static, IGP, etc. These communities are used along with additional logic in route policies to determine which routes are to be announced to which eBGP peers and which are to be dropped. Route policy is applied to eBGP sessions based on what set of routes they should receive (transit, full routes, internal-only, default-only, etc.). In this process, the ISP's AS also ensures that routes learned from a transit-provider or a lateral peer (i.e. non-transit) at an ingress router are not leaked at an egress router to another transit-provider or peer. Additionally, in many cases, ISP network operators' outbound policies require explicit matches for expected communities before passing routes. This helps ensure that that if an update has made it into the routing table (i.e. RIB) but has missed its ingress community tagging (due to a missing/misapplied ingress policy), it will not be inadvertently leaked.” Question: Are there other means of conveying this information in common use today (i.e. for prevention of route leaks)? Also, the following publicly available references can be possibly cited in support of the above: https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf http://showipbgp.com/bgp-tools/bgp-community-list/91-level3-as3356.html Pointers to any other relevant references would be very welcome as well. Thank you. Sriram
