Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-08.txt

[Brian E Carpenter <[e-mail]>]

On 13-Jul-22 17:00, Christian Huitema wrote:
> 
> On 7/12/2022 9:03 PM, Brian E Carpenter wrote:
>> On 13-Jul-22 15:46, Bernard Aboba wrote:
>>>> On Jul 12, 2022, at 20:03, Brian E Carpenter
>>>> <[e-mail]> wrote:
>>>> People writing fault-tolerant software will draw their own conclusions.
>>>
>>> [BA] Looking at the document examples there are several cases of
>>> poorly written specifications. The Robustness Principle doesn’t
>>> condone that, nor does it preclude rejecting nonconformant inputs
>>> when there are good reasons to do so (e.g. security). If the spec is
>>> vague in places, if there are known interop issues, by all means fix
>>> it. It’s the Robustness principle, not the Don’t Worry Be Happy
>>> principle.
>>>
>>> There is another thing that bothers me, which is the problem of
>>> untested code paths. Greasing alone cannot solve this. The Robustness
>>> Principle mostly applies to expected conditions. Many security
>>> vulnerabilities fall into these unexpected cracks. The best tool I
>>> have seen us a formal state machine analysis to identify attack
>>> vectors. Robustness Principle doesn’t preclude that either.
>>
>> Would a state machine analysis detect possible race conditions? These
>> are not mentioned in the draft, and I think they're the sort of corner
>> case that the robustness principle should help with.
> 
> 
> You need to distinguish between testing communication protocols and
> testing software. The "untested code paths" that Bernard mentions are
> more often software coding issues than protocol design issues.
> 
> If you are concerned that a succession of transitions drives the
> protocol state into untested territory, then it is much safer to stop
> sooner, e.g., close the connection with a "local error" diagnostic when
> things start looking iffy. The opposite would be to tolerate operation
> in modes that have not been tested yet, and that's exactly when bad
> stuff happens.

Absolutely, and that's another approach to robust software of course:
when the "impossible" happens, kill everything and start again. That
works whether the problem is a protocol design error or an implementation
error.

    Brian