- Test - lists.nanog.org

BGP Error Handling (Fwd: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04)
by Rob Shakir 12 Jun '12

12 Jun '12

Hi NANOGers, Back at NANOG51 in Miami, I gave a presentation relating an IETF draft relating to improving the robustness of BGP-4 to meet the requirements of current operational deployments, and there was some good discussion following this. This document was then presented to the IETF IDR and GROW (Global Routing Operations WG), and we have since iterated the document to make it significantly clearer, and describe the desired operational behaviour. This work was particularly on the back of the issues that were seen in the Internet DFZ relating to malformed AS_PATH, invalid AS4_PATH, and the problematic RIPE NCC large optional-transitive advertisement. The discussion, and the requirements outlined have helped influence a number of new standards developments in BGP: - An IDR BGP error handling draft [0] is in progress to standardise the "treat-as-withdraw" behaviour, which allows session resets to be avoided based on erroneous BGP UPDATEs where possible. - Further drafts relating to extending ROUTE REFRESH [1] and Graceful Restart [2] have been proposed to allow recovery from inconsistent RIB states, and reduced impact to forwarding when a session reset cannot be avoided respectively. - The work that Tom Scholl, Richard Steenbergen, John Scudder, and David Freedman did on the ADVISORY message has been extended to handle some error handling cases, as well as the original use case [3]. The working group last call represents final agreement prior to publishing this work, which is valuable since it provides a framework of requirements which future developments are intended to solve. I would encourage anyone who has an interest in this area to review the document, and let the GROW mailing list (grow(a)ietf.org) know whether the requirements describe meet their use case, and/or any comments or deviations that should be noted. Many thanks in advance for doing so - there are a number of network scenarios that I think will be operationally improved by implementing this work. Kind regards, r. Begin forwarded message: > From: Christopher Morrow <christopher.morrow(a)gmail.com> > Subject: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 > Date: 11 June 2012 21:21:49 GMT+01:00 > To: grow-chairs(a)tools.ietf.org, "grow(a)ietf.org grow(a)ietf.org" <grow(a)ietf.org> > > Hello GROW-WG folk, > Please take this message as the start of a 2 week, ending 6/25/2012 > (June 25, 2012) WGLC for the subject draft, link to current version: > <http://www.ietf.org/internet-drafts/draft-ietf-grow-ops-reqs-for-bgp-error-…> > > Abstract: > "BGP-4 is utilised as a key intra- and inter-Autonomous System routing > protocol in modern IP networks. The failure modes as defined by the > original protocol standards are based on a number of assumptions > around the impact of session failure. Numerous incidents both in the > global Internet routing table and within Service Provider networks > have been caused by strict handling of a single invalid UPDATE > message causing large-scale failures in one or more Autonomous > Systems. > > This memo describes the current use of BGP-4 within Service Provider > networks, and outlines a set of requirements for further work to > enhance the mechanisms available to a BGP-4 implementation when > erroneous data is detected. Whilst this document does not provide > specification of any standard, it is intended as an overview of a set > of enhancements to BGP-4 to improve the protocol's robustness to suit > its current deployment." > > -Chris > co-chair > _______________________________________________ > GROW mailing list > GROW(a)ietf.org > https://www.ietf.org/mailman/listinfo/grow

1 0

Re: Configuration Systems
by Andrew Latham 12 Jun '12

12 Jun '12

Jonathan That is the exact question I have asked myself many times. All of the major players in Configuration management have a "client" program that must run and at times requires some libraries that are newer than the platforms a company may need to support or that clients may wish supported. Another issue is the secure communication over a proprietary or SSH connection and not allowing secured VLANs or other services like RSH and Telnet over a point to point connection. Also you will find that the demand for cloud systems and the complex languages used in the "Configuration Management Systems" do not easily translate to the existing and developing cloud infrastructure. and stuff... On Wed, Jun 6, 2012 at 10:52 PM, Jonathan Herbert <jwherbert(a)gmail.com> wrote: > Hi Andrew, > > Out of curiosity, why are you reinventing the wheel here? > > Don't take this the wrong way- I'm just curious why you're building > something new. What does Enablement do that the other technologies you've > mentioned doesn't? > > Jonathan > > > On Wed, Jun 6, 2012 at 10:49 PM, Andrew Latham <lathama(a)gmail.com> wrote: >> >> Lurker speaking... beware... >> >> I have been talking with some folks from various industries about >> configuration systems ala Bcfg2, Puppet, Chef, and others. Many of >> them care far too much about the current nodes configuration status as >> some admin had logged in and changed something. I am authoring a >> system called Enablement that uses what ever technology needed (ssh, >> telnet over admin vlan, rsh, etc...) to push a planned system/config >> to the device. Monitoring and auditing are all the same at the moment >> as we need historical data on when a service or port started and >> stopped offering its planned or unplanned service. For a meeting >> Thursday I am looking forward to the future of configuring systems. >> My idea is push + netblock scanning of services. With stacks for >> clouds we can startup and shut down nodes easy. Would a bend over >> backwards config reader for all the "Configuration Management Systems" >> be the best medium ground from the service provider point of view? >> >> Enablement.... Send another man to fight on the front line. >> >> -- >> ~ Andrew "lathama" Latham lathama(a)gmail.com http://lathama.net ~ >> > -- ~ Andrew "lathama" Latham lathama(a)gmail.com http://lathama.net ~

9 13

Re: Dear Linkedin,
by Scott Weeks 11 Jun '12

11 Jun '12

--- jna(a)retina.net wrote: From: John Adams <jna(a)retina.net> I use 1password, you might use LastPass. They both work on Android, iPhone, Linux, Mac, Windows. ---------------------------------------- No, according to their site 1password does not work on *nix, however lastpass says it does all *nix flavors. scott

5 4

Arbor Peakflow competitor?
by bas 11 Jun '12

11 Jun '12

Hi All, Has anyone worked with GenieATM? http://www.genienrm.com/index.php/products/9-genieatm/genieatm-6000/21-geni… It looks as it has the same functionality as Peakflow. I'm curious if anyone has tested or deployed the solution. And if so, what are your experiences? Thanks in advance, Bas

3 2

Re: Dear Linkedin,
by Scott Weeks 11 Jun '12

11 Jun '12

--- gabe(a)teksavvy.ca wrote: From: Gabriel Blanchard <gabe(a)teksavvy.ca> How the heck did this conversation go from Linkedin to a Quebec drivers license? I'm not sure how relevant this is to NANOG. Both subject matters that is. ------------------------------ New to nanog, eh? ;-) scott

1 0

My view of the arin db boarked?
by Christopher Morrow 11 Jun '12

11 Jun '12

err, last 3 times I asked this I was shown the error of my ways, but here goes... 209.250.228.241 - seems to not have any records in ARIN's WHOIS database, everythign seems to roll up to the /8 record :( I see this routed as a /23: (from routeviews) BGP routing table entry for 209.250.228.0/23, version 2072545487 Paths: (33 available, best #19, table Default-IP-Routing-Table) Not advertised to any peer 3277 3267 174 27431 14037 194.85.102.33 from 194.85.102.33 (194.85.4.4) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65321 3277:65323 3277:65330 If I look at the ASN in particular: AS14037 no records exist for that in ARIN's WHOIS database either ;( If I look at all the networks announced by AS14037: 14037 | 204.8.216.0/21 | 14037 | 209.250.224.0/19 | 14037 | 209.250.228.0/23 | 14037 | 209.250.242.0/24 | 14037 | 209.250.247.0/24 | 14037 | 64.18.128.0/19 | 14037 | 64.18.159.0/24 | none of them have any records in the ARIN WHOIS database :( The upstream for this network is AS 27431 - JTL Networks who seems to get transit/peer with 3356/174. It's nice to see folk who use IRR databases to filter their customers still permit this sort of thing to go on though: AS3356 I'm looking at you... I think first: "Where are the records for this set of ip number resources?" and second: "Why are we still seeing this on the network with no way to contact the operators of the resources?" -chris

3 5

Problems connecting to Web-sites hosted by XO/Concentric
by Syed Knut A. 11 Jun '12

11 Jun '12

Hi, Some of our customers (BKK Fiber is an ISP) are having problems connecting to Web-services (TCP port 80) hosted by XO/Concentric. tcpdump shows that no packets are returned. Ping and connection to the SMTP-service (TCP port 25) on the Webserver hosts are fine. The problem seem to be limited to customers within a certain /17 allocated to us. I have tried Customer Care to no help. Has anybody else experienced the same with XO/Conecentric? Does anybody have contact information to Concentric operations? Kind Regards, Knut A. Syed Senior Network Engineer BKK Fiber AS | Postboks 7050, 5020 Bergen | T: +47 55 12 75 53 | M: +47 916 39 767 | www.bkk.no<http://www.bkk.no/> ___________________________________________________ This message and any attachment is intended for the person(s) named above only. It may contain information that is confidential or legally privileged. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank You. This footnote confirms that the email and attachment(s) has been swept by our anti-virus solution for the presence of known computer viruses.

1 0

ROVER routing security - its not enumeration
by Daniel Massey 11 Jun '12

11 Jun '12

Hi, Just wanted to clarify a few things about the ROVER approach. One key misunderstanding seems to be that ROVER is an approach for enumerating all potentially valid routes. This is not the case. Slides on ROVER are posted for the NANOG 55 talk and there was an additional Lightning talk Monday in NANOG A good summary of misunderstandings are listed below and addressed below: > Summarizing a few other things other people have mentioned: > > - The normal operating mode with RPKI is to fetch everything rather > than do a point query. We've spent the last decade or so making > that harder to do with DNS (blocking AXFR/IXFR, using NSEC3 instead > of NSEC, etc). This makes it fairly difficult to know in advance > what queries one should be asking ROVER (as Paul Vixie puts it, > ROVER isn't a catalogue). When I pressed the ROVER folks about this > at the Paris IETF meeting, they mumbled something about maybe > walking the IRR or other external databases as a way of knowing what > DNS queries to issue. ROVER's operational model is ask a question and get an answer. ROVER is not an enumeration method. RPKI does provide enumeration, but ROVER is not trying to duplicate RPKI. I think the first step is to step back and ask whether every operational model needs enumeration. For example, the talk yesterday by Level3 used the DNS and IRR did not need such an enumeration. Enumeration is not a goal in itself. There are number of operational models that provide the needed routing protection without enumeration. > - Circular dependencies are a problem. Helical dependencies can be > made to work, but this says that one probably should not be > depending on routing to make a point query to make decisions about > routing. If you look at the architecture of the existing RPKI > validators (well, mine and BBN's, anyway, not sure about RIPE's but > suspect they took the same approach), we've gone to some trouble to > make sure that the validator will continue to work across network > outages as long as the collected data haven't expired or been > revoked. In theory one could do the same thing with bulk transfers > of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it > would not work well with point queries. Or a simpler approach that does not require bulk zone transfers or zone walking is simply DNS caching, which already exists and is well understood. More broadly, whether one calls its a cache or RPKI validator or whatever, you can build it with redundancy. One can certainly make either system work across network outages. > - ROVER gives us no traction on path validation (BGPSEC), it's limited > to origin validation. RPKI can certify both prefixes and ASNs, > which gives it the basics needed to support path validation as well > as origin validation. ASNs have no hierarchical structure, thus > would be a very poor match for encoding as DNS names. The focus is on origin and sub prefix hijacks. There are certainly discussions and early experiments with future additions, but the work is focused on origin/subprefix events. > - Some of the DNS aspects of ROVER are a little strange. In > particular, as currently specified ROVER requires the relying party > to pay attention to DNS zone cuts, which is not normal in DNS (the > basic DNS model since RFC 883 has been that zones are something for > the zone administrator to worry about, resolvers mostly just see a > tree of RRsets). ROVER requires the relying party to check for the > same data in multiple zones and pay close attention to zone cuts. > While it is certainly possible to do all this, it is not a matter of > issuing a simple DNS query and you're done. DNS caching effects can > also complicate matters here if the zone structure is changing: > think about what happens if you have cached responses to some (but > not all) of the queries you need to make to figure out whether to > allow a more specific route punched out of a larger prefix block. > This is a misunderstanding of the ROVER approach. Multiple copies of the data do not exist in multiple zones. There is a one-to-one mapping between a prefix and a DNS name. The resolver simply finds the data and has no need to understand where zone cuts occur. On the other hand, DNS administrators do care about how they make zone cuts and delegate to their customers. They can take a /16 and delegate two /17's, or they can manage the whole thing in a single zone. Their choice. A resolver simply issues a query for the unique DNS name associated with a prefix. This could be done with anything from a complex tool set to a simply command line tool like dig. The confusion here may arise from what happens if you get an *authenticated* response saying there is no routing data at this name. This could mean 1) the prefix should not be announced or 2) the reverse DNS happens to be signed with DNSSEC but the site is not participating in routing security via DNS. To determine this, you issue a second query. Is an RLOCK present along with the DNSKEY used to sign the data? The existence of an RLOCK proves participation. > - The reuse of existing infrastructure argument for ROVER is somewhat > disingenuous -- it's only partial reuse of existing infrastructure. > ROVER's new encoding of prefixes as DNS names means that a lot of > new stuff would need to be deployed, and attempting to be backwards > compatible with the existing DNS reverse tree adds some complexity > to ROVER's architecture I strongly disagree with this. ROVER does use a naming convention. This is simply a convention, not a protocol change. The best analogy here is that one may have an internal naming convention for naming routers or particular servers or so forth. You should follow this convention and build this into your provisioning scripts where appropriate. Clearly it is enormously better if there is a consistent way to name prefixes so we have a common convention for naming the data. Everyone putting data in is using the convention and we are working to get the convention standardized. The convention is also useful for storing data at prefixes; geolocations is one example. > (conflicting data for same prefix can appear > in multiple zones, relying party has to sort this out, yum). Again, this is simply a naming convention. There is a unique name for a prefix. To DNS, this is a name like any other name. A DNS name belongs to a zone. It cannot appear in multiple zones. The prefix has a unique name. The name cannot appear in multiple zones. ROVER is not trying to do exactly what RPKI is doing. Much of this seems to be an attempt to build a form of enumeration into ROVER. See the Level3 NANOG talk from Monday (6/4/12) for a concrete example of a different model. There are many different operational models. We seek a common convention for data publishing, but believe strongly there can and should be different operational models for how you do validation in your network. Thanks, Dan and Joe

7 12

Dear Linkedin,
by Michael Thomas 11 Jun '12

11 Jun '12

Linkedin has a blog post that ends with this sage advice: * Make sure you update your password on LinkedIn (and any site that you visit on the Web) at least once every few months. I have accounts at probably 100's of sites. Am I to understand that I am supposed to remember each one of them and dutifully update them every month or two? * Do not use the same password for multiple sites or accounts. So the implication is that I have 100's of passwords all unique and that I must change every one of them to be something new and unique every few months. And remember each of them. And not write them down. * Create a strong password for your account, one that includes letters, numbers, and other characters. And that each of those passwords needs to be really hard to guess that I change to every few months on 100's of web sites. I'm sorry, my brain doesn't hold that many passwords. Unless you're a savant, neither does yours. So what you're telling me and the rest of the world is impossible. What's most pathetic about this is that somebody actually believes that we all really deserve this finger wagging. Mike

19 37

Timeframe for LinkedIn Attack?
by Oliver Garraux 11 Jun '12

11 Jun '12

Hey, I'm curious if anyone has heard of a possible timeframe for the LinkedIn attack? I use different email aliases on most websites I sign up for. (So I can identify where a spammer got my email address from and so I can just remove the alias if I get spammed a lot). I've been testing some scripts I wrote to parse through my email logs recently, and noticed a few interesting log entries from back in May. I have accounts on Last.fm and on LinkedIn (using email aliases). I received a spam message on the email alias I use for LinkedIn on May 10. I also received four spam messages on the email alias I use for Last.fm on May 10. The LinkedIn related message came in at 20:22 UTC. The four Last.fm messages came in between 21:26 and 21:51 UTC. All of these messages were rejected because the IP the connection came from was listed on Spamhaus’s XBL (they came from 5 different IP's). I don't think this necessarily proves anything beyond a shadow of a doubt - but it seems really suspicious to me, given that I've never seen any other spam directed to these address before or after May 10, and that the email addresses for both of these sites that were compromised were spammed for the first time on the same day. (And none of the other 100+ email aliases I have received spam for the first time on that day). This would suggest to me that LinkedIn and Last.fm may have been compromised at least a month ago. Has anyone else seen anything that would confirm or refute this? Oliver ------------------------------------- Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux

2 1