4 ms·

> When they receive something that they don't understand they need to propagate without breaking connection, and they do not. And this is how things are done,

> When they receive something that they don't understand they need to propagate without breaking connection, and they do not. And this is how things are done, per the article: > On 2 June 2023, a small Brazilian network (re)announced one of their internet routes with a small bit of information called an attribute that was corrupted. The information on this route was for a feature that had not finished standardisation, but was set up in such a way that if an intermediate router did not understand it, then the intermediate router would pass it on unchanged. > As many routers did not understand this attribute, this was no problem for them. They just took the information and propagated it along. However, the information was corrupted at the source, and those devices that did understand the attributed detected the corruption and rejected it: > However it turned out that Juniper routers running even slightly modern software did understand this attribute, and since the attribute was corrupted the software in its default configuration would respond by raising an error that would shut down the whole BGP session. The question is whether the session shutdown was appropriate (at least by default). I think Juniper's default is reasonable, as attributes can communicate important information about the intentions of the network operators, and rejecting a particular attribute and basically ignoring the intentions of the operators may also cause problems. 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 current behavior is akin to an HTTP server shutting down whenever it receives an invalid HTTP request. Or, for an even better analogy, it is like an HTTP server that, upon receiving a malformed HTTP request, drops all current and future traffic from that IP. A malicious user can then issue a malformed HTTP request through an open proxy, and deny all other connections to that server throgh that proxy for all other users who were sending proper requests.
- throw0101c 3y ago
  > The current behavior is akin to an HTTP server shutting down whenever it receives an invalid HTTP request. It is nothing like that. HTTP requests do not propagate across an organization's entire network, or possibly the entire Internet. > Or, for an even better analogy, it is like an HTTP server that, upon receiving a malformed HTTP request, drops all current and future traffic from that IP. So just like (e.g.) fail2ban blocking IPs that continuously send bad login requests? That's awesome! I would want my web server to block bad clients. Heck, it would be nice if web browsers would do the same thing with content they downloaded. In the early days of the web there were all sorts of garbage files out there and instead of forcing people to correct their HTML they tried to be clever in mind reading: * https://en.wikipedia.org/wiki/Tag_soup https://en.wikipedia.org/wiki/Tag_soup For a time there was an entire 'movement' to get people to clean up their act: * https://en.wikipedia.org/wiki/W3C_Markup_Validation_Service https://en.wikipedia.org/wiki/W3C_Markup_Validation_Service * https://en.wikipedia.org/wiki/HTML_Tidy https://en.wikipedia.org/wiki/HTML_Tidy It's fine to have a flag to have stringency be a policy that can be toggled, but I think Postel's law ("be liberal in what you accept") can cause issues over the long-term: * https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
  - fanf2 3y ago
    It’s like your origin web server unceremoniously dropping the http connection when its front end reverse proxy (fastly, cloudfront, akamai, etc) forwards an invalid request, and when your web server restarts the proxy retries the bad request.
  - tsimionescu 3y ago
    > So just like (e.g.) fail2ban blocking IPs that continuously send bad login requests? That's awesome! I would want my web server to block bad clients. Well, somewhat, except that it's not awesome. It's like fail2ban, but implemented on a server that sits behind a load balancer. So, when it receives a bad login request from an IP and it bans that IP, it actually banned the IP of the load balancer, so now it won't receive any other requests. So that a malicious client can just send 1 bad request, and take down everyone else using the whole server. Basically, this whole discussion is not so much about Postel's law, it's about limiting failure domains. A bad route advertisement should make that 1 route inaccessible. It is not good design for a bad route advertisement to take down all the other good routes. It is particularly bad design for a protocol where routes are automatically propagated by devices that don't think there's anything wrong with them. If you want to compare it to the HTML situation, the bug can also be seen as a browser that, when it receives invalid HTML from www.google.com/search would not only throw an error, but also refuse any other connection to *.google.com/*. The proposed fix is not to interpret anything as valid HTML. It is to show an error only when accessing www.google.com/search.
ExoticPearTree 3y ago
> However, the information was corrupted at the source, and those devices that did understand the attributed detected the corruption and rejected it. No they did not, they shutdown a whole session down for a malformed announcement. The right decision would have been to ignore the corrupt attribute and maybe not install that particular route. A logged message saying "Attribute 129 with value 0 is invalid" would have helped operators more than just blindly shutting down sessions through which this was announced.
- fanf2 3y ago
  The right decision is specified in RFC 7606, which is usually to treat the malformed announcement as a withdrawal. (BGP attributes cannot in general be discarded safely.)

tsimionescu 3y ago

The current behavior is akin to an HTTP server shutting down whenever it receives an invalid HTTP request. Or, for an even better analogy, it is like an HTTP server that, upon receiving a malformed HTTP request, drops all current and future traffic from that IP. A malicious user can then issue a malformed HTTP request through an open proxy, and deny all other connections to that server throgh that proxy for all other users who were sending proper requests.

throw0101c 3y ago
> The current behavior is akin to an HTTP server shutting down whenever it receives an invalid HTTP request. It is nothing like that. HTTP requests do not propagate across an organization's entire network, or possibly the entire Internet. > Or, for an even better analogy, it is like an HTTP server that, upon receiving a malformed HTTP request, drops all current and future traffic from that IP. So just like (e.g.) fail2ban blocking IPs that continuously send bad login requests? That's awesome! I would want my web server to block bad clients. Heck, it would be nice if web browsers would do the same thing with content they downloaded. In the early days of the web there were all sorts of garbage files out there and instead of forcing people to correct their HTML they tried to be clever in mind reading: * https://en.wikipedia.org/wiki/Tag_soup https://en.wikipedia.org/wiki/Tag_soup For a time there was an entire 'movement' to get people to clean up their act: * https://en.wikipedia.org/wiki/W3C_Markup_Validation_Service https://en.wikipedia.org/wiki/W3C_Markup_Validation_Service * https://en.wikipedia.org/wiki/HTML_Tidy https://en.wikipedia.org/wiki/HTML_Tidy It's fine to have a flag to have stringency be a policy that can be toggled, but I think Postel's law ("be liberal in what you accept") can cause issues over the long-term: * https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
- fanf2 3y ago
  It’s like your origin web server unceremoniously dropping the http connection when its front end reverse proxy (fastly, cloudfront, akamai, etc) forwards an invalid request, and when your web server restarts the proxy retries the bad request.
- tsimionescu 3y ago
  > So just like (e.g.) fail2ban blocking IPs that continuously send bad login requests? That's awesome! I would want my web server to block bad clients. Well, somewhat, except that it's not awesome. It's like fail2ban, but implemented on a server that sits behind a load balancer. So, when it receives a bad login request from an IP and it bans that IP, it actually banned the IP of the load balancer, so now it won't receive any other requests. So that a malicious client can just send 1 bad request, and take down everyone else using the whole server. Basically, this whole discussion is not so much about Postel's law, it's about limiting failure domains. A bad route advertisement should make that 1 route inaccessible. It is not good design for a bad route advertisement to take down all the other good routes. It is particularly bad design for a protocol where routes are automatically propagated by devices that don't think there's anything wrong with them. If you want to compare it to the HTML situation, the bug can also be seen as a browser that, when it receives invalid HTML from www.google.com/search would not only throw an error, but also refuse any other connection to *.google.com/*. The proposed fix is not to interpret anything as valid HTML. It is to show an error only when accessing www.google.com/search.

ExoticPearTree 3y ago

> However, the information was corrupted at the source, and those devices that did understand the attributed detected the corruption and rejected it. No they did not, they shutdown a whole session down for a malformed announcement. The right decision would have been to ignore the corrupt attribute and maybe not install that particular route. A logged message saying "Attribute 129 with value 0 is invalid" would have helped operators more than just blindly shutting down sessions through which this was announced.

fanf2 3y ago
The right decision is specified in RFC 7606, which is usually to treat the malformed announcement as a withdrawal. (BGP attributes cannot in general be discarded safely.)