Re: It's been 20 years today (Oct 16, UTC). Hard to believe.
--- rjoffe@centergate.com wrote: From: Rodney Joffe <rjoffe@centergate.com> At NANOG two weeks ago, we had an interesting discussion at one of the lunch tables. One of the subjects we discussed was the original IANA, and RFC Editor, Jon Postel. Seven of the ten people at the table had never heard of him. Maybe these days it no longer matters who he was, and what he meant to where we are today. ------------------------------------------------ Wow, was it a table of folks new to network engineering? If so, then schooling; if not, then clue bat... :-) scott
at 1:11 PM, Scott Weeks <surfer@mauigateway.com> wrote:
Wow, was it a table of folks new to network engineering? If so, then schooling; if not, then clue bat... :-)
scott
The one thing I remember about Postel, other than the fact that he had his fingers in a lot of DNS pies, is be liberal about what you accept, be conservative about what you send. It’s a notion that creates undo burden on the implementor, because it places the expectation on the that you need to account for every conceivable ambiguous corner case and that’s not always the best approach when implementing a standard; and it mostly arises from the lack of adherence to the second part of that statement.
On Tue, Oct 16, 2018 at 02:01:48PM -0400, Daniel Corbe wrote:
The one thing I remember about Postel, other than the fact that he had his fingers in a lot of DNS pies, is be liberal about what you accept, be conservative about what you send. It’s a notion that creates undo burden on the implementor, because it places the expectation on the that you need to account for every conceivable ambiguous corner case and that’s not always the best approach when implementing a standard; and it mostly arises from the lack of adherence to the second part of that statement.
I think that his aphorism is simply a recognition that NO standard can cover all cases that might arise when dealing with complex matters, no matter how much thought went into it. People are fallible, and the standards they write are inevitably flawed in some way, so a realistic implementor has to allow some slack or be continually engaged in finger-pointing when something doesn't work. - Brian
Well, simply put, the idea is that you should be able to compensate for a certain amount of deviation from accepted usage as long as its still within what the protocol allows (or can be read to allow) but that you yourself should act with a fairly strict interpretation. In others, don't be the one *causing* the problems... On Tue, Oct 16, 2018 at 11:10:31AM -0700, Brian Kantor wrote:
On Tue, Oct 16, 2018 at 02:01:48PM -0400, Daniel Corbe wrote:
The one thing I remember about Postel, other than the fact that he had his fingers in a lot of DNS pies, is be liberal about what you accept, be conservative about what you send. It???s a notion that creates undo burden on the implementor, because it places the expectation on the that you need to account for every conceivable ambiguous corner case and that???s not always the best approach when implementing a standard; and it mostly arises from the lack of adherence to the second part of that statement.
I think that his aphorism is simply a recognition that NO standard can cover all cases that might arise when dealing with complex matters, no matter how much thought went into it. People are fallible, and the standards they write are inevitably flawed in some way, so a realistic implementor has to allow some slack or be continually engaged in finger-pointing when something doesn't work. - Brian
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
On Oct 16, 2018, at 4:57 PM, Wayne Bouchard <web@typo.org> wrote:
Well, simply put, the idea is that you should be able to compensate for a certain amount of deviation from accepted usage as long as its still within what the protocol allows (or can be read to allow) but that you yourself should act with a fairly strict interpretation. In others, don't be the one *causing* the problems...
Indeed. To give a TCP example, the opening exchange is theoretically SYN, SYN ACK, ACK. A common case is that it is SYN, SYN ACK, data, either because the ACK got lost, or because someone cut a corner. The issue is to note that the SYN might have been duplicated in flight, and the receiver might therefore have the appearance of two sessions. Which one? The ACK (or data segment) - any segment within the sessions - clarifies that. So, if there is a minor protocol violation but the intent it clear, follow the intent. The alternative version of the Robustness Principle: "S**t happens; deal with it." Says someone who has implemented such things... -------------------------------------------------------------------------------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu
What it's trying to say is that you have control over your own code but not others', in general. So make your own code (etc) robust and forgiving since you can't edit others' code to conform to your own understanding of what they should be sending you. I suppose that pre-dates github but nonetheless much of the code which generates bits flung at you is proprietary and otherwise out of your control but what you can control is your code's reaction to it. And of course the bits you generate which should try to make conservative assumptions about what they might accept and interpret as you expect. For example just because they sent you a seemingly malformed HTTP request, and given that 4xx is for error codes, doesn't mean you should return "420 You must be high!" and expect to be understood. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others. Mike On 10/16/2018 07:18 PM, bzs@theworld.com wrote:
What it's trying to say is that you have control over your own code but not others', in general.
So make your own code (etc) robust and forgiving since you can't edit others' code to conform to your own understanding of what they should be sending you.
I suppose that pre-dates github but nonetheless much of the code which generates bits flung at you is proprietary and otherwise out of your control but what you can control is your code's reaction to it.
And of course the bits you generate which should try to make conservative assumptions about what they might accept and interpret as you expect.
For example just because they sent you a seemingly malformed HTTP request, and given that 4xx is for error codes, doesn't mean you should return "420 You must be high!" and expect to be understood.
On October 16, 2018 at 19:35 mike@mtcc.com (Michael Thomas) wrote:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Security fits into all this, being liberal in what you accept doesn't mean you do whatever they ask. Quite the contrary it means make sure your code doesn't roll over dead or misbehaving just because you received an unexpected input. Not doing that was exactly what allowed for example buffer overflow attacks. The target software wasn't liberal in what it accepts which is to say anticipated that someone might send them a very long string and should either buffer it correctly or truncate it. They assumed they'd only be sent reasonably short strings.
Mike
On 10/16/2018 07:18 PM, bzs@theworld.com wrote:
What it's trying to say is that you have control over your own code but not others', in general.
So make your own code (etc) robust and forgiving since you can't edit others' code to conform to your own understanding of what they should be sending you.
I suppose that pre-dates github but nonetheless much of the code which generates bits flung at you is proprietary and otherwise out of your control but what you can control is your code's reaction to it.
And of course the bits you generate which should try to make conservative assumptions about what they might accept and interpret as you expect.
For example just because they sent you a seemingly malformed HTTP request, and given that 4xx is for error codes, doesn't mean you should return "420 You must be high!" and expect to be understood.
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On 10/16/2018 08:20 PM, bzs@theworld.com wrote:
On October 16, 2018 at 19:35 mike@mtcc.com (Michael Thomas) wrote:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Security fits into all this, being liberal in what you accept doesn't mean you do whatever they ask.
Quite the contrary it means make sure your code doesn't roll over dead or misbehaving just because you received an unexpected input.
That's not the same thing. That's never acceptable. Trying to educe what a sender really meant is a good way to create exploitable spaghetti though. But don't take my word for it, reach out to people who pay more attention to such things than me. Mike
On Tue, Oct 16, 2018, 22:37 Michael Thomas <mike@mtcc.com> wrote:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Mike
I saw just a small swing of the pendulum toward the center, a nuanced meaning for "liberal". The adage wasn't tossed out. Operationally it can't be. Scott
On 10/16/2018 08:36 PM, Scott Brim wrote:
On Tue, Oct 16, 2018, 22:37 Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Mike
I saw just a small swing of the pendulum toward the center, a nuanced meaning for "liberal". The adage wasn't tossed out. Operationally it can't be.
All of the security types were pretty unanimous when this came up during all of the dkim stuff i worked on. I was a fan, and I got schooled. Mike
* Scott Brim:
On Tue, Oct 16, 2018, 22:37 Michael Thomas <mike@mtcc.com> wrote:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Mike
I saw just a small swing of the pendulum toward the center, a nuanced meaning for "liberal". The adage wasn't tossed out. Operationally it can't be.
I think DMARC, as it is deployed right now, pretty much killed the “liberal” part for many people. It's sender policy, but it's necessarily enforced at the recipient end, but many recipients aren't given a choice to opt out when it is technically the wrong thing to do. You can switch email providers, but as the IETF never really designed for email address portability, that's a theoretical option only for many.
I'm probably going to regret posting this but I think most of this dispute regarding Jon Postel's advice revolves around how the words "liberal" and "conservative" have changed over 20 years. Liberal used to mean adaptable, open-minded, and conservative used to mean cautious and hewing close to the rules (and I mean none of that disparagingly.) <IGNORE> I won't begin to characterize how these words have changed but, um, ach, phffft, AGHHH!...they didn't mean calling your personal prostitute a "horseface" or arguing that point via the public internet. </IGNORE> -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On Tue, 16 Oct 2018, Michael Thomas wrote:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Postel's Law is about robustness of network communications. As such it can *increase* network security by improving availability [CIA triad] although it could potentially reduce confidentiality and integrity in some circumstances. Whether or not Postel's Law improves or degrades security would need to be assessed on a case by case basis. Cheers, Rob
On 2018-10-17 02:35, Michael Thomas wrote:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Postel's maxim also allowed extensibility. If our network code rejects (or crashes) on things we don't currently understand and use, it ensures that they can't be used by apps that come along later either. The attitude of rejecting everything in the name of security is what has forced app developers to tunnel APIs and everything else inside HTTP/DNS.
Mike
On 10/16/2018 07:18 PM, bzs@theworld.com wrote:
What it's trying to say is that you have control over your own code but not others', in general.
So make your own code (etc) robust and forgiving since you can't edit others' code to conform to your own understanding of what they should be sending you.
I suppose that pre-dates github but nonetheless much of the code which generates bits flung at you is proprietary and otherwise out of your control but what you can control is your code's reaction to it.
And of course the bits you generate which should try to make conservative assumptions about what they might accept and interpret as you expect.
For example just because they sent you a seemingly malformed HTTP request, and given that 4xx is for error codes, doesn't mean you should return "420 You must be high!" and expect to be understood.
* Laszlo Hanyecz:
On 2018-10-17 02:35, Michael Thomas wrote:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Postel's maxim also allowed extensibility. If our network code rejects (or crashes) on things we don't currently understand and use, it ensures that they can't be used by apps that come along later either. The attitude of rejecting everything in the name of security is what has forced app developers to tunnel APIs and everything else inside HTTP/DNS.
To be fair, a lot of these components that make extending protocols hard are both receivers and senders. If they are asked to forward garbage, then something has to give.
On 10/17/2018 12:43 PM, Florian Weimer wrote:
* Laszlo Hanyecz:
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others. Postel's maxim also allowed extensibility. If our network code rejects (or crashes) on things we don't currently understand and use, it ensures
On 2018-10-17 02:35, Michael Thomas wrote: that they can't be used by apps that come along later either. The attitude of rejecting everything in the name of security is what has forced app developers to tunnel APIs and everything else inside HTTP/DNS.
Let's be clear: crashing is a software bug. It has nothing to do with Postel. On the extensibility part, that is for the protocol itself to define, and it should be explicit. If the protocol says to reject, then you must reject. I'm not sure if extensibility one of the global protocol check offs, but it certainly should be part of any stander.
To be fair, a lot of these components that make extending protocols hard are both receivers and senders. If they are asked to forward garbage, then something has to give.
Yes, the protocol should tell you what to do. If it doesn't, its deficient. Mike
For example just because they sent you a seemingly malformed HTTP request, and given that 4xx is for error codes, doesn't mean you should return "420 You must be high!" and expect to be understood.
Actually, you can, and the sender of the request MUST understand. The relevant part of the applicable RFC says: HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
participants (12)
-
Brian Kantor -
bzs＠theworld.com -
Daniel Corbe -
Florian Weimer -
Fred Baker -
Keith Medcalf -
Laszlo Hanyecz -
Michael Thomas -
Robert Brockway -
Scott Brim -
Scott Weeks -
Wayne Bouchard