4 ms·

Yes, I know about BGP propagation works. My point still stands: attributes can have important information about the intentions of how a network operator wishes

Yes, I know about BGP propagation works. My point still stands: attributes can have important information about the intentions of how a network operator wishes their network to be seen to the rest of the world. Having a corrupt attribute, and thinking it's okay to simply assume that without that attribute the rest of the advertisement is still valid is not fine IMHO: you're basically trying to guess/assume the intentions of the source of the advertisement. For all we know ignoring that attribute and accepting the rest of the advertisement as-is could have caused flood of traffic over the connection causing a just-as-effective-DoS.

tsimionescu 3y ago
That is not what is being done. If you advertise a route with a corrupt attribute, your route will be considered inaccessible by any device that understands the attribute. But! All your other routes that you advertised earlier with perfectly fine attributes will continue working. This is what prevents this from becoming a DoS vulnerability. Let's take a more complete example. ISP1 advertises 2 routes to ISP2: 35.67.0.0/16 attr1=val1 37.61.0.0/16 attr1=corr ISP2 doesn't know what attr1 is, and it advertisea the following routes to ISP3: 35.67.0.0/16 attr1=val1 37.61.0.0/16 attr1=corr 78.0.0.0/8 The bug is that ISP3 will then stop routing any traffic to 35.67.0.0/16, 37.61.0.0/16, or to 78.0.0.0/8. After the fix, ISP3 will keep routing traffic to 35.67.0.0/16 (respecting the value val1 for attribute attr1) and to 78.0.0.0/8 through ISP2. It will not route traffic to 37.61.0.0/16.
fanf2 3y ago
As the fine article explains, your concerns are addressed by RFC 7606. It recommends that in many cases, an error should be treated as a route withdrawal, not by dropping the session. (The RFC specifies other ways to handle errors in specific situations.) There’s no guessing or assuming. In the scenario that started off the author’s investigation, the bad attribute kicked COLT off the Internet even though COLT did not connect directly to the Brazilian ISP that sent the bad route update. When they received the bad update, COLT’s routers dropped their BGP sessions with intermediate ISPs that were unrelated to the Brazilian ISP, causing complete loss of connectivity. If COLT’s routers had treated the error as a route withdrawal, they would have lost connectivity to the Brazilian ISP but not the rest of the Internet.

tsimionescu 3y ago

That is not what is being done. If you advertise a route with a corrupt attribute, your route will be considered inaccessible by any device that understands the attribute. But! All your other routes that you advertised earlier with perfectly fine attributes will continue working. This is what prevents this from becoming a DoS vulnerability. Let's take a more complete example. ISP1 advertises 2 routes to ISP2: 35.67.0.0/16 attr1=val1 37.61.0.0/16 attr1=corr ISP2 doesn't know what attr1 is, and it advertisea the following routes to ISP3: 35.67.0.0/16 attr1=val1 37.61.0.0/16 attr1=corr 78.0.0.0/8 The bug is that ISP3 will then stop routing any traffic to 35.67.0.0/16, 37.61.0.0/16, or to 78.0.0.0/8. After the fix, ISP3 will keep routing traffic to 35.67.0.0/16 (respecting the value val1 for attribute attr1) and to 78.0.0.0/8 through ISP2. It will not route traffic to 37.61.0.0/16.

fanf2 3y ago

As the fine article explains, your concerns are addressed by RFC 7606. It recommends that in many cases, an error should be treated as a route withdrawal, not by dropping the session. (The RFC specifies other ways to handle errors in specific situations.) There’s no guessing or assuming. In the scenario that started off the author’s investigation, the bad attribute kicked COLT off the Internet even though COLT did not connect directly to the Brazilian ISP that sent the bad route update. When they received the bad update, COLT’s routers dropped their BGP sessions with intermediate ISPs that were unrelated to the Brazilian ISP, causing complete loss of connectivity. If COLT’s routers had treated the error as a route withdrawal, they would have lost connectivity to the Brazilian ISP but not the rest of the Internet.