4 ms·

Bad input -> shutdown provides a method by which an external attacker can shut down your service by providing bad input, otherwise known as a denial of service

Bad input -> shutdown provides a method by which an external attacker can shut down your service by providing bad input, otherwise known as a denial of service attack.

throw0101c 3y ago
The input in question was a particular attribute: these attributes can have important information about the intentions of how the operators wish things to work. Simply ignoring the bad input and carrying on the BGP session without the attribute(s) in question may lead to working against the desired intentions of the network operators. I think Juniper's default is reasonable: rejecting a particular attribute and basically ignoring the intentions of the operators could also cause problems, and instead of trying to read the minds of those running the networks, the software doesn't try to be clever. I also think that thinking that perhaps allowing the session to continue but throwing a (loud) warning is also reasonable (and there is a flag for that).
- tsimionescu 3y ago
  The problem is that one bad route in a BGP session caused the whole session to shut down. So if ISP1 advertises a new route with a corrupted attribute to ISP2 who doesn't understand it, and ISP2 advertises it to ISP3 who does understand the corrupted attribute, all traffic between ISP2 and ISP3 will shut down. So ISP1 has caused communication failure between ISP2 and ISP3 for all clients, not just for its own routes.
  - throw0101c 3y ago
    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.

Bad input -> shutdown provides a method by which an external attacker can shut down your service by providing bad input, otherwise known as a denial of service attack.

throw0101c 3y ago

The input in question was a particular attribute: these attributes can have important information about the intentions of how the operators wish things to work. Simply ignoring the bad input and carrying on the BGP session without the attribute(s) in question may lead to working against the desired intentions of the network operators. I think Juniper's default is reasonable: rejecting a particular attribute and basically ignoring the intentions of the operators could also cause problems, and instead of trying to read the minds of those running the networks, the software doesn't try to be clever. I also think that thinking that perhaps allowing the session to continue but throwing a (loud) warning is also reasonable (and there is a flag for that).

tsimionescu 3y ago
The problem is that one bad route in a BGP session caused the whole session to shut down. So if ISP1 advertises a new route with a corrupted attribute to ISP2 who doesn't understand it, and ISP2 advertises it to ISP3 who does understand the corrupted attribute, all traffic between ISP2 and ISP3 will shut down. So ISP1 has caused communication failure between ISP2 and ISP3 for all clients, not just for its own routes.
- throw0101c 3y ago
  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.